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ABSTRACT 


This  dissertation  expands  the  current  method  of  development  and  validation  of 
conceptual  models  (CoM)  of  non-observable  systems  (NOSs)  by  using  systems 
engineering  (SE)  and  systems  architecture  (SA)  methods  during  the  model  development 
process  (MDP).  A  MDP  is  used  to  ensure  that  the  models  are  validated  and  represent  the 
real  world  as  accurately  as  possible.  There  are  several  varieties  of  MDPs  presented  in 
literature,  but  all  share  the  importance  of  the  CoM.  The  improved  conceptual  model 
methodology  (ICoMM)  is  developed  in  support  of  improving  the  structure  of  the  CoM 
for  both  face  and  traces  validation.  The  utility  of  ICoMM  is  demonstrated  through  the 
building  of  functional,  physical,  and  allocated  architecture  products  that  improve  the 
structure  of  the  CoM  for  traces  validation.  ICoMM  also  incorporates  a  value  model  to 
ensure  subject  matter  experts’  (SMEs’)  values  are  documented  early  in  the  MDP  for  face 
validation.  A  well-constructed  CoM  supports  model  exploration  of  NOS  when 
operational  validation  is  not  feasible.  This  dissertation  uses  a  humanitarian 
assistance/disaster  relief  (HA/DR)  scenario  to  demonstrate  ICoMM’ s  ability  to  ensure 
documentation  of  SMEs’  values  and  that  the  structure  of  the  COM  links  SMEs’  values  to 
the  fundamental  objective. 
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EXECUTIVE  SUMMARY 


This  dissertation  focuses  on  the  importance  of  validation  of  conceptual  models 
(CoMs)  early  in  the  model  development  process  (MDP)  by  improving  the  structure  of 
CoMs.  A  validated  CoM  early  in  the  MDP  also  supports  the  operational  validation  of  a 
classification  of  systems  known  as  non-observable  systems  (NOSs).  It  presents  the  use  of 
systems  engineering  (SE)  and  systems  architecting  (SA)  methods  to  improve  design  and 
structure  of  the  CoM  to  help  decision  makers  (DMs)  rely  on  the  validation  process  to 
gain  trust  in  the  model. 

Conceptual  models  are  built  to  provide  a  visual  depiction  of  an  idea  of  a  system 
that  addresses  deficiencies  in  the  real  world.  Several  works  pertaining  to  the  development 
of  models  state  the  importance  of  the  CoMs.  However,  literature  is  lacking  on  how  to 
build  the  CoMs  that  facilitate  conceptual  validation  and  support  operational  validation  of 
NOS. 

This  research  presents  an  improved  conceptual  model  methodology  (ICoMM)  that 
supports  the  building  of  validated  conceptual  models  with  an  improved  structure  and 
involvement  of  SMEs  early  in  the  MDP.  Figure  1  presents  Sargent’s  evolved  MDP.  The 
ICoMM  is  implemented  within  Sargent’s  evolved  MDP  to  improve  the  structure  of  the 
CoM  (Sargent  2001,  109).  This  research  uses  Sargent’s  evolved  MDP  to  examine  the 
development  of  models  (Sargent  2001).  Sargent’s  evolved  MDP  identifies  two  worlds, 
real  and  simulation.  The  real  world  is  where  deficiencies  and  requirements  for  systems 
are  identified.  The  ideas  of  systems  that  have  the  potential  to  address  the  deficiencies  are 
identified  in  “systems  theories”  (Sargent  2001,  109).  Systems  theories  provide  the  bridge 
between  the  real  and  simulation  worlds.  The  simulation  is  where  models  are  built  and 
experiments  are  conducted.  It  begins  with  building  of  the  CoM.  The  CoM  is  built  based 
on  the  systems  theories  identified  in  the  real  world.  This  dissertation  has  identified  a  lack 
of  methodology  on  building  a  well-structured  CoM. 
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Figure  1. 


Sargent’s  Evolved  Model  Development  Process 
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Source:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying  and 
Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation  Conference , 
109. 


ICoMM  provides  three  areas  of  improvement  within  Sargent’s  evolved  MDP 
depicted  by  white  circles  with  numbers  as  seen  in  Figure  2.  The  first  circle  is  the 
transition  from  systems  theories  to  the  CoM.  Systems  engineering  and  systems 
architecture  processes  are  applied  to  design,  decomposition,  and  construction  of  a  CoM 
based  on  the  operational  concept  of  the  system  developed  in  the  real  world.  The 
improved  structure  identifies  the  measurement  at  the  lowest  level  and  links  it  to  a  single 
fundamental  objective  to  facilitate  trace  validation.  The  second  circle  shows  the  improved 
structure  of  the  CoM  that  emphasizes  the  greater  incorporation  of  documenting  SME 
values  to  facilitate  face  validation.  The  improved  structure  of  the  conceptual  model 


xx 


facilitates  both  top-down  and  bottom-up  passing  of  information  to  support  traces 
validation.  The  third  circle  is  an  improved  definition  of  systems  that  are  non-observable 
within  the  context  of  a  MDP.  This  dissertation  supplements  the  definition  of  NOS  to  also 
include  future  conceptual  models,  which  the  interaction  between  the  conceptual  system 
and  an  external  system  may  not  be  observable.  It  demonstrates  that  a  well-structured 
CoM  supports  the  operational  validation  of  a  NOS  with  the  inability  to  observe  system 
behavior  during  execution  of  a  simulation  through  model  exploration  of  the  CoM. 


Adapted  from:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying 
and  Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation 
Conference,  109. 


The  ICoMM  is  conducted  in  a  sequence  of  four  phases,  each  defined  by  activities 
and  products  that  support  the  three  areas  of  contribution  mentioned  earlier.  Figure  3 
shows  the  visualization  of  ICoMM.  ICoMM  begins  by  using  an  operational  concept  to 
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create  a  system  to  address  the  identified  need  of  the  stakeholders.  Next,  a  CoM  is  created 
using  SE  and  SA  to  visually  model  the  system  and  its  components,  as  well  as  its 
interaction  with  the  external  system  based  on  the  operational  concept.  The  CoM  then 
goes  through  two  validations  processes,  face  and  traces  validations.  Finally,  operational 
validation  of  NOS  is  conducted  using  model  exploration  supported  by  the  validated  CoM. 


Figure  3.  Improved  Conceptual  Model  Methodology  Visualization 
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ICoMM  was  applied  to  a  Department  of  Defense  (DOD)  humanitarian 

assistance/disaster  relief  (HA/DR)  mission  scenario.  ICoMM  was  compared  to  previous 

research  using  the  same  scenario.  The  result  of  this  research  revealed  that  applying  SE 

and  SA  methods  in  model  development  improved  the  structure  of  the  CoM.  The  new 

structure  facilitated  the  traceability  of  multiple  measurements  of  functions  to  a  single 

fundamental  objective,  as  opposed  to  the  multiple  objectives  identified  in  previous 

research.  It  also  identified  the  functions  and  components  of  the  external  system  that 

affected  the  fundamental  objective.  ICoMM  also  established  measures  to  hold  SMEs 

accountable  by  documenting  their  values  of  the  functions  to  be  executed  by  the  system 
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supporting  face  validation.  Finally,  using  the  ICoMM  created  a  validated  CoM  prepared 
to  conduct  model  exploration.  This  dissertation  did  not  attempt  to  simulate  the  HA/DR 
mission.  The  scope  of  this  research  was  to  improve  system  definition  and  model  structure 
from  the  previous  research. 

The  intent  of  ICoMM  is  to  be  used  in  multiple  scenarios.  It  is  applied  when 
developing  systems  that  are  conceptual  in  nature  to  address  needs  in  the  real  world. 
ICoMM  improved  the  structure  of  the  CoM  to  ensure  traceability  to  a  single  fundamental 
objective  and  SMEs  participation  early  in  the  MDP.  If  applied  correctly,  analysts  can 
present  DMs  a  well-structured  model  they  can  trust  to  make  decisions  that  impact  the 
entire  organization. 
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I. 


INTRODUCTION 


The  use  of  modeling  and  simulation  (M&S)  is  an  important  aspect  of  the 
development  of  systems.  An  important  aspect  of  M&S  is  the  validation  of  the  models  to 
ensure  that  the  models  accurately  represent  the  system  in  the  real  world.  Validated 
models  ensure  that  decision  makers  (DMs)  are  able  to  trust  the  results  of  the  model  to 
make  decisions.  This  dissertation  addresses  the  need  for  improvement  of  the  validation 
methods  of  conceptual  models  (CoMs)  to  support  operational  validation  of  non¬ 
observable  systems  (NOSs).  It  presents  the  use  of  systems  engineering  (SE)  and  systems 
architecting  (SA)  methods  to  improve  design  and  structure  of  the  conceptual  model  that, 
in  turn,  will  help  DMs  rely  on  the  validation  process  to  gain  trust  in  the  model. 

A  system,  defined  by  the  International  Council  of  Systems  Engineering  (INCOSE), 
is  “a  construct  or  collection  of  different  elements  that  together  produce  results  not  obtained 
by  the  elements  alone”  (INCOSE  2015).  Some  systems  are  so  large  and  complex  that 
models  of  the  system  must  be  made  to  achieve  better  understanding  of  how  the  actual 
system  will  perform  in  the  real  world  (Parnell,  Driscoll,  and  Henderson  2011).  Models  are 
abstract  representations  of  an  actual  system  and  are  built  before  a  system  is  fully  produced 
or  executed  in  the  real  world.  Models  are  used  to  better  understand  aspects  of  the  system 
that  may  not  be  identified  in  the  real  world  (Sokolowksi  and  Banks  2009,  5). 

Several  model  development  processes  (MDPs)  are  presented  in  the  literature  as 
guides  to  building  models  that  represent  systems.  The  evolved  MDP  of  Sargent  (2001)  is 
the  primary  example  used  in  this  dissertation.  In  his  earlier  work,  Sargent  (1984) 
introduces  several  concepts  used  for  this  research,  such  as  CoM  validation  and  NOSs, 
which  are  discussed  in  detail  in  Chapter  II. 

As  the  models  of  systems  go  through  the  MDP,  the  models  must  be  conceptually 
and  operationally  validated  to  ensure  the  model  adequately  reflects  the  user’s  needs  and 
gains  the  trust  of  DMs.  The  Department  of  Defense  (DOD)  (2008)  defines  validation  as 
“the  process  of  determining  the  degree  to  which  a  model,  simulation,  or  federation  of 
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model  and  simulations  (M&S)  and  their  associated  data  are  accurate  representation  of  the 
real  world  form  the  perspective  of  the  intended  use(s)”  (3). 

Figure  1  displays  the  evolved  Sargent’s  MPD  presented  in  2010.  The  first  phase 
of  Sargent’s  evolved  MDP  is  to  build  the  CoM.  The  CoM  is  a  description  of  how  the 
functions  of  the  system  will  be  executed  to  achieve  the  fundamental  objectives  defined  by 
the  DMs  (Law  2007,  255).  A  detailed  structured  CoM  provides  traceability  from 
performance  measurements  to  the  achievement  of  the  fundamental  objective.  The 
traceability  supports  the  validation  of  the  CoM. 


Figure  1.  Evolved  Sargent’s  Model  Development  Process 
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Source:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying  and 
Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation  Conference , 
109. 
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Sargent  (1984)  presents  two  methods  of  CoM  validation,  face  and  traces 
validation  techniques.  Face  validation,  as  Sargent  describes  it,  involves  subject  matter 
experts  (SMEs)  with  knowledge  of  the  system,  stating  whether  the  design  of  the 
conceptual  model  is  accurate  and  the  input-output  of  the  model  is  reasonable.  Also 
known  as  a  “peer  assessment,”  it  is  a  subjective,  yet  effective  method  to  evaluate  models 
(Balci  1986).  The  other  CoM  validation  method  is  traces  validation.  Traces  validation 
follows  the  logic  of  the  model  to  determine  if  the  model  is  accurate  and  meets  the  need  of 
the  user  (Sargent  1984).  A  validated  CoM  supported  by  the  two  validation  methods 
contributes  to  the  operational  validation  of  the  model  performed  later  in  the  MDP. 

Operational  validation  of  the  model  is  to  determine  if  the  model’s  output  meets 
the  intended  purpose  of  the  model.  An  important  factor  that  affects  the  operational 
validation  is  whether  the  system  is  observable  or  non-observable  (Sargent  1984).  It  is 
possible  to  collect  data  on  the  operational  behavior  for  observable  systems,  while  it  is  not 
possible  for  NOSs.  Sargent  (1984)  uses  two  types  of  approaches  for  operational 
validation,  subjective  and  objective,  for  both  types  of  systems.  There  are  two  subjective 
approaches  for  operational  validation  of  NOSs,  exploration  of  model  behavior  and 
comparison  to  other  models.  The  objective  approach  described  by  Sargent  uses 
comparison  to  other  models  using  statistical  tests  (Sargent  1984).  An  example  of  NOSs  is 
future  conceptual  systems  that  are  not  in  existence.  The  only  operational  validation 
method  that  can  be  used  for  future  conceptual  systems  is  the  subjective  approach  of 
exploring  model  behavior  (Sargent  2013).  Future  CoMs  are  systems  that  are  not  in 
existence  and  have  no  other  systems  or  models  of  system  to  compare.  Operational 
validation  of  the  models  of  future  conceptual  systems  is  unfeasible  if  it  is  used  in  “what- 
if’  environments  or  is  used  to  forecast  system  results  (Balci  1986).  The  model  output 
behavior(s)  must  be  thoroughly  explored  to  improve  the  confidence  in  the  model  of  a 
NOS  (Sargent  2013). 

This  dissertation  presents  the  idea  that  deviations  from  the  intended  outputs 
identified  as  a  result  of  the  simulation  of  a  model  of  a  NOS  must  be  referred  back  to  the 
CoM  for  model  exploration.  The  structure  of  the  CoM  is  reexamined  to  identify  functions 
or  objectives  that  may  contribute  to  the  deviation  of  the  intended  output.  Based  on  the 
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updated  information,  DMs  are  able  to  make  decisions  quickly  to  adjust  their  course  of 
action,  identify  new  objectives,  or  give  greater  weight  to  different  functions.  It  is  assumed 
that  if  the  simulation  results  of  models  of  NOSs  were  as  intended,  the  validated  CoM 
would  support  operational  validation  and  no  further  action  would  be  needed. 

A.  BACKGROUND 

Throughout  history,  people  have  used  models  to  represent  ideas,  buildings, 
weapons,  and  even  armies.  Sokolowski  and  Banks  (2009)  use  the  game  of  chess, 
developed  in  the  15th  century,  to  provide  an  example  of  M&S  in  history.  The 
fundamental  objective  in  chess  is  to  obtain  “checkmate,”  by  capturing  the  king. 

The  chess  pieces  represent  the  components  of  the  system,  the  chessboard  is  the 
simulated  battlefield,  and  the  execution  of  the  game  is  the  simulation  (Sokolowski  and 
Banks  2009).  The  game  of  chess  can  be  seen  as  the  origin  of  the  modern-day  war  game. 
A  set  of  rules  outlines  the  functions  of  the  pieces.  The  user  determines  the  strategy  used 
to  execute  the  functions.  Chess  is  a  classic  example  of  how  DMs  have  used  M&S  to 
understand  the  system  and  the  functions  of  components  to  achieve  a  fundamental 
objective. 

As  time  progressed,  systems  have  become  more  complex.  Modem  buildings  are 
taller,  weapons  are  more  lethal,  and  armies  are  bigger  with  capabilities  beyond  what  was 
imagined  when  chess  was  developed  in  the  15th  century.  However,  models  are  still  used 
by  engineers,  scientists,  and  analysts  to  help  gain  better  understanding  of  these  complex 
systems.  Models  have  also  become  complex  to  represent  complex  systems. 

Models  are  used  to  represent  ideas  either  to  improve  an  existing  system  or  to 
introduce  an  entire  new  system  to  provide  for  a  new  need.  These  types  of  models  are 
known  as  CoMs  that  are  “theoretical  representation  of  systems  based  on  anecdotal  or 
scientific  observations”  (Parnell,  Driscoll,  and  Henderson  2011,  104).  CoM  development 
is  the  first  task  identified  in  several  MDPs.  The  CoM  provides  the  initial  understanding  of 
the  purpose,  assumptions,  components,  relationships,  and  interactions  of  the  system. 
Diagrams  and  flow  charts  are  used  to  create  CoM.  These  drawings  include  a  purpose, 
input  variables,  output  variables,  and  controls  of  the  CoM.  The  Integration  Definition  for 
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Function  Modeling  (IDEFO)  language  used  in  SE  is  a  tool,  which  formally  describes  the 
system.  The  IDEFO  is  used  by  this  dissertation  and  is  further  discussed  in  Chapter  II. 

It  is  important  that  the  DMs  trust  the  CoM  accurately  represents  the  system  to 
accept  and  use  the  model.  The  CoM  must  be  validated  to  gain  the  confidence  and  trust  in 
the  model.  Sargent  defines  CoM  validation  as  “determining  that  the  theories  and 
assumptions  underlying  the  conceptual  model  are  consistent  with  those  in  the  system 
theories  and  that  the  model  representation  of  the  system  is  ‘reasonable’  for  the  intended 
purpose  of  the  simulation  model”  (Sargent  1984,  118). 

B.  PREVIOUS  RESEARCH 

Many  articles  have  been  published  pertaining  to  the  concept  of  CoMs  and  the 
validation  of  models.  However,  most  refer  to  the  definitions  of  CoMs  and  their  validation 
presented  by  Robert  Sargent.  In  1979,  Sargent  wrote  one  of  the  earliest  publications  in 
the  area  of  validation  and  presented  a  simplified  model  development  process.  The 
simplified  process  had  three  nodes  that  represented  the  system:  problem  entity, 
conceptual  model,  and  computerized  model.  Between  each  of  the  nodes  is  either  a 
validation  or  verification  that  was  conducted  to  ensure  the  model  in  each  node  accurately 
represented  the  system  as  it  progressed  through  the  MDP.  Sargent  identified  the  CoM 
also  as  a  “flowchart,”  which  led  to  the  assumption  that  a  flow  chart  was  the  primary 
method  to  represent  the  CoM.  Sargent  also  presented  various  validation  techniques  to 
include  face  and  traces  validation.  Sargent  subsequently  published  articles  on  verification 
and  validation  (V&V)  of  models,  introducing  new  concepts  every  few  years. 
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Figure  2.  Initial  Version  of  Sargent’s  Model  Development  Process 


Source:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying  and 
Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation  Conference, 
108. 


In  Sargent’s  (1984)  proceedings  of  the  winter  simulation  conference,  Sargent 
introduced  the  idea  of  CoM  validation  and  the  techniques  used  for  validation.  The  CoM 
validation  determines  whether  appropriate  structure,  logic,  and  relationships  are 
identified.  In  this  article,  Sargent  specifically  identifies  face  and  traces  validation 
techniques  to  be  used  to  validate  CoMs.  He  also  states  that  operational  validation  is 
affected  by  whether  or  not  the  operational  behavior  of  the  system  is  observable.  A  system 
is  classified  as  observable  if  it  is  possible  to  collect  data  on  the  operational  behavior 
(Sargent  1984).  Sargent  uses  two  types  of  approaches  for  operational  validation, 
subjective  and  objective,  for  both  types  of  systems.  There  are  two  subjective  approaches 
for  operational  validation  of  NOSs,  exploration  of  model  behavior  and  comparison  to 
other  models.  The  objective  approach  only  uses  comparison  to  other  models  using 
statistical  tests.  Sargent  does  not  discuss  observable  systems  and  NOSs  in  this  article. 
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In  1986,  in  Bald’s  proceedings  of  the  Winter  Simulation  Conference,  Balci 
introduced  a  MDP  similar  to  Sargent’s  MDP.  Balci’ s  MDP  had  several  additional  steps 
compared  to  Sargent’s.  However,  the  idea  of  developing  the  CoM  and  validating  the 
overall  model  remains  the  same  as  Sargent’s  model.  The  idea  of  using  SMEs  for  model 
validation  was  also  reinforced  by  Balci.  He  stated  that  peer  assessment  is  an  effective 
method  for  evaluating  the  acceptability  of  the  model  results  (Balci  1986).  Peer  assessment 
consists  of  a  panel  of  experts  who  evaluates  the  system  based  on  their  knowledge  of  the 
system.  Balci  (1986)  also  introduced  the  idea  that  SMEs  identify  indicators,  an  indirect 
measure  of  concepts:  “The  indicators  are  weighted  and  measured  with  an  overall  score” 
(40).  However,  validation  may  be  unfeasible  if  the  model  is  applied  as  a  forecasting  model 
to  answer  the  “what  if’  questions  of  a  system  model  (Balci  1986). 

In  2001,  Sargent  improved  the  MDP,  first  presented  in  1984.  His  evolved  MDP  is 
divided  into  two  worlds,  the  real  and  simulation.  The  real  world  is  where  the  system 
resides  and  the  models  of  the  system  are  in  the  simulation  world.  Sargent  increases  the 
number  of  phases  to  five  in  the  simulation  world  in  the  evolved  MDP  from  the  previous 
three  phases.  The  evolved  MDP  has  the  system  theories  reside  in  both  the  real  and  the 
simulation  world  to  serve  as  a  conduit  between  the  two  worlds.  The  four  remaining 
phases  in  the  simulation  world  are  the  CoM,  simulation  model  specification,  simulation 
model,  and  the  simulation  model  data/results  (Sargent  2001).  The  CoM  is  the  logical 
representation  of  the  system.  The  simulation  model  specification  is  the  detailed  software 
program  written  to  implement  the  CoM  in  the  simulation.  The  program  must  be  verified 
to  ensure  the  programming  code  is  appropriate  for  the  particular  computer  used  for 
simulation.  The  simulation  is  the  execution  of  the  CoM  in  the  computer.  Finally,  the 
simulation  model  data  and  results  are  the  outputs  of  the  simulation  (Sargent  2001). 
Sargent  adds  that  high  degree  of  confidence  is  difficult  to  obtain  for  NOSs.  Thus,  he  finds 
that  model  exploration  of  the  behavior  output  should  be  explored  and  compared  to  other 
validated  models  if  possible. 

In  2014,  Andrew  Turner  conducted  research  on  developing  models  for  the 
simulation  of  NOSs.  Turner’s  research  is  the  first  attempt  to  develop  a  method  to  model 
NOSs.  Turner  uses  Bald’s  1986  MDP  to  support  his  methodology.  However,  Turner 
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(2014)  identifies  the  primary  shortcomings  of  his  methodology  as  linking  the  steps  of  the 
MDP  and  correctly  identifying  the  structure  of  the  system  impacts  on  decomposition. 
Turner  (2014),  in  his  future  works  section,  states  that  “continued  research  would 
investigate  a  process  to  enable  a  better  transition  from  system  definition  to  impact 
variable  decomposition”  (330).  The  structure  presented  by  Turner  does  not  link  the 
measurements  from  the  lowest  levels  in  his  structure  and  does  not  lead  to  a  single 
fundamental  objective. 

C.  GAP 

Research  into  improving  CoMs  provides  insights  into  the  challenges  faced  by 
analysts  to  create  models  for  simulation  that  can  be  trusted  by  DMs,  especially  if  the 
systems  are  non-observable.  The  research  gap  identified  by  this  dissertation  is  the  lack  of 
a  method  to  build  well-structured  CoMs.  This  dissertation  presents  the  idea  that  a  well- 
structured  conceptual  model  supports  both  conceptual  and  operational  validations. 
Currently,  there  is  a  lack  of  research  into  the  design  of  the  CoM  to  support  validation 
with  SME  involvement  and  a  logical  structure.  A  validated  CoM  also  supports 
operational  validation  of  NOS.  An  operational  validation  is  unfeasible  when  the  behavior 
of  a  model  of  a  system  is  non-observable  during  the  execution  of  a  simulation.  The  only 
way  to  make  sense  of  the  simulation  results  is  to  conduct  model  exploration  (Sargent 
2007).  There  are  no  current  methods  of  exploring  models  of  NOS.  The  CoM  is  the  only 
model  available  for  model  exploration  of  NOS.  This  dissertation  emphasizes  the  idea  that 
an  improved  structure  of  the  CoM  provides  increased  traceability  and  greater 
accountability  of  SMEs. 

Turner’s  work  on  modeling  of  NOSs  for  simulations  is  significant  because  it  is 
unique.  All  other  references  to  NOSs  in  the  body  of  literature  have  been  to  define  the 
term  and  the  concepts.  It  does  not  demonstrate  how  to  build  the  models  or  validate  them 
for  system  use  in  the  real  world.  Turner  uses  the  limited  information  within  the  body  of 
knowledge  to  present  a  method  of  modeling  NOSs. 

Finally,  Turner  identifies  two  areas  of  continued  work  in  the  field  of  modeling  of 
NOSs  for  simulation  at  the  end  of  his  research.  It  is  in  these  areas  where  further 
contributions  to  the  body  of  knowledge  are  made: 
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•  Better  transition  from  system  definition  to  impact  variable  decomposition. 

•  Proper  development  of  structure  for  decomposition  (Turner  2014,  330). 

Again,  SE  methods  are  used  in  this  research  to  continue  the  previous  work  to 
improve  the  method  of  validation  of  models  of  NOSs  so  they  are  traceable  and  support 
current  SME  validation  methods. 

Current  research  does  not  present  methods  to  document  SMEs  values  for  face 
validation.  Sargent  notes  that  faces  validation  involves  SMEs,  but  does  not  present  how 
to  involve  SMEs  in  the  development  of  models.  There  is  also  a  lack  of  literature  of  how 
to  conduct  model  exploration  should  the  output  of  the  simulation  deviate  from  the 
intended  output. 

The  following  research  questions  arise  as  a  result  of  these  identified  gaps: 

•  Is  there  a  formal  method  of  building  a  CoM  of  a  system?  If  not,  what  are 
the  methods  available  to  build  a  CoM  system? 

•  What  improvements  can  be  made  to  the  structure  of  the  CoM  to  improve 
traceability  of  the  model  for  validation? 

•  How  can  SMEs  values  be  documented  to  support  CoM  development  and 
accountability  during  face  validation? 

•  Does  model  exploration  of  the  CoM  of  a  NOS  support  operational 
validation? 

•  Can  improving  the  CoM  by  using  SE  and  SA  methods  support  conceptual 
and  operational  validation  when  applied  to  a  study  of  DOD  organizational 
system  during  a  humanitarian  assistance/disaster  relief  operation 
(HA/DR)? 

D.  CONTRIBUTION 

The  primary  contribution  of  this  dissertation  is  the  M&S  domain.  Figure  3  shows 
the  areas  of  contribution  as  noted  by  the  three  white  circles  and  the  corresponding  numbers. 
This  dissertation  presents  a  methodology  that  improves  of  the  structure  of  the  CoM  for 
validation  from  previous  research.  The  first  circle  is  the  transition  from  systems  theories  to 
the  CoM.  Systems  engineering  and  systems  architecture  processes  are  applied  to  design, 
decompose,  and  construct  a  CoM  based  on  the  operational  concept  of  the  system  developed 
in  the  real  world.  The  improved  structure  identifies  the  measurement  at  the  lowest  level  and 
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links  them  to  a  single  fundamental  objective  to  facilitate  trace  validation.  The  second  circle 
shows  the  improved  structure  of  the  CoM  that  emphasizes  the  greater  incorporation  of 
documenting  SME  values  to  facilitate  face  validation.  The  improved  structure  of  the 
conceptual  model  facilitates  both  top-down  and  bottom-up  passing  of  information  to 
support  traces  validation.  The  third  circle  is  an  improved  definition  of  systems  that  are  non¬ 
observable  within  the  context  of  a  MDP.  It  adds  to  the  definition  that,  for  future  conceptual 
models,  the  interaction  between  the  conceptual  system  and  an  external  system  may  not  be 
observable.  This  dissertation  demonstrates  that  a  well-structured  CoM  supports  the 
operational  validation  of  a  NOS  with  the  inability  to  observe  system  behavior  during 
simulation  execution  through  model  exploration  of  the  CoM. 


Adopted  from:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying 
and  Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation 
Conference,  109. 
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E.  RESEARCH  APPROACH 


This  dissertation  presents  a  methodology  to  present  DMs  with  a  visual  CoM.  The 
idea  of  building  a  CoM  is  taken  a  step  further  by  establishing  a  methodology  based  on  SE 
and  SA  concepts  and  assert  that  the  methodology  improves  CoM  validation.  This 
research  acknowledges  that  the  methodology  presents  only  a  small  improvement  on  the 
foundation  of  the  idea  of  CoMs  and  its  validation.  However,  it  does  address  specific  areas 
of  improvement  identified  by  previous  research,  systems  definition,  and  structure.  Future 
works  section  points  to  the  areas  that  should  be  examined  as  further  research  in  this  area. 

The  result  of  the  research  is  the  formalization  of  an  Improved  Conceptual  Model 
Methodology  (ICoMM).  ICoMM  was  used  to  build  a  CoM  of  the  HA/DR  mission  used 
by  a  previous  research  to  demonstrate  the  improved  method  of  defining  the  system  and 
structure  of  the  model. 

F.  DISSERTATION  ORGANIZATION 

Chapter  II  reviews  model  development  processes  and  validation  methods.  System 
engineering  and  systems  architecture  are  also  reviewed.  It  covers  systems  design  and 
architecting  techniques  to  decompose  a  system  to  understand  its  requirements,  the 
functions  and  the  components,  and  how  it  interacts  with  an  external  system.  The 
definition  of  NOS  is  explored  to  gain  an  understanding  of  the  challenges  of  modeling 
NOS  and  its  operational  validation. 

Chapter  III  presents  the  improved  conceptual  model  methodology  (ICoMM). 
ICoMM  uses  SE  and  SA  processes  to  improve  the  structure  of  the  CoM  that  facilitates 
validation. 

Chapter  IV  demonstrates  the  utility  of  this  research  by  exploring  the  conceptual 
modeling  of  NOSs.  A  humanitarian  assistance/disaster  relief  (HA/DR)  scenario  used  in 
previous  research  is  explored  in  this  research  to  improve  the  design  of  the  interaction 
between  the  system  and  the  external  system.  SE  and  architecting  principles  are  applied  to 
show  improved  traceability  from  the  measurements  of  performance  and  effectiveness  to 
the  fundamental  objective. 
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Chapter  V  concludes  the  dissertation  with  a  summary  of  the  research  and 
contributions.  Recommendations  for  extensions  of  this  research  are  included  in  the  future 
works  section. 
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II.  LITERATURE  REVIEW 


The  focus  of  this  dissertation  is  improving  the  CoM  by  establishing  a  structure 
that  supports  face  and  traces  validation  of  the  CoM.  It  also  investigates  the  operational 
validation  of  NOSs.  This  dissertation  presents  the  integration  of  SE  and  SA  methods  to 
improve  the  structure  of  COMs.  Face  validation  is  also  enhanced  by  inclusion  of  SMEs’ 
values  early  in  the  MDP. 

It  is  important  to  establish  a  baseline  of  understanding  of  models  and  how  models 
help  to  gain  insights  of  systems.  First,  this  chapter  reviews  the  definition  of  models  and 
its  uses.  Next,  a  review  of  several  MDPs  is  presented  with  an  emphasis  on  Sargent’s 
(2001)  evolved  MDP.  Sargent’s  evolved  method  for  model  development  is  the  foundation 
of  this  dissertation.  According  to  Sargent  (1984),  there  are  two  main  model  validation 
phases  of  the  MDP,  the  CoM  validation,  and  the  operational  validation.  SE  and  SA 
methodologies  are  review  to  understand  how  a  system  is  decomposed  to  identify  its 
functions  and  components.  The  decomposition  of  the  systems  helps  to  improve  the 
structure  of  the  CoM  and  its  validation.  Operational  validation  is  conducted  based  on  the 
results  of  a  simulation  (Sargent  2010).  For  NOS,  operational  validation  is  difficult  due  to 
its  complexity. 

Many  categories  of  systems  already  exist  in  the  SE  domain.  Blanchard  and 
Fabry cky  (2006)  describe  a  few  of  the  classifications  of  systems,  such  as  natural  and 
human-made,  physical  and  conceptual,  static  and  dynamic,  closed  and  open  systems.  This 
chapter  reviews  the  classification  of  systems  known  as  observable  systems  and  NOSs  to 
identify  the  differences  and  how  both  are  operationally  validated.  The  term  NOS  is  a 
difficult  concept  to  understand  and  not  used  very  often  in  the  M&S  domain. 

Very  little  is  written  on  the  subject  of  NOSs  within  the  M&S  domain.  To  gain  an 
understanding  of  modeling  NOS,  it  is  important  to  establish  a  foundation  of 
understanding  of  the  definition,  engineering,  design,  and  architecture  of  systems.  Parnell, 
Driscoll,  and  Henderson  (2011)  acknowledge  that  analysts  must  consider  the 
interdisciplinary  systems  thinking  approach  to  model  systems.  The  MDP  and  the 
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validation  techniques  are  discussed  to  present  SE  integration  into  a  MDP.  This  chapter 
also  establishes  how  a  validated  COM  supports  the  operational  validation  of  NOS. 

A.  MODELS 

Models  are  important  tools  in  today’s  society.  People  depend  on  models  in 
everyday  life,  from  the  engineer  who  tries  to  improve  the  structure  of  an  airplane  to 
architect  who  strives  to  build  a  more  efficient  home.  In  similar  ways,  models  help  DMs 
gain  information  about  systems  to  make  decisions.  Thus,  a  model  is  defined  as  “an 
abstract  representation  of  a  system”  (Parnell,  Driscoll,  and  Henderson  2011,  99). 

1.  Model  Development  Processes 

It  is  imperative  that  all  models  go  through  a  MDP.  A  MDP  can  be  as  informal  as  a 
simple  drawing  on  a  napkin  or  as  formal  as  a  methodology  presented  in  an  engineering 
class.  In  1979,  Robert  Sargent  presented  his  simplified  version  of  the  MDP  during  the 
Winter  Simulation  Conference.  Since  then,  many  others  have  presented  different  MDPs. 
However,  Sargent’s  MDP  has  been  the  main  source  cited  by  many  in  the  model 
development  community  and  THER  DOD.  There  have  been  several  updates  to  Sargent’s 
1979  MDP;  however,  the  basic  concepts  of  model  development  remain  relevant. 

a.  Early  Sargent’s  Model  Development  Processes 

Sargent  used  his  simplified  modeling  process  model  to  explain  the  verification 
and  validation  steps  necessary  during  the  modeling  process.  This  dissertation  refers  to 
this  process  as  the  “Sargent  circle,”  as  it  was  used  in  Turner’s  (2014)  dissertation. 

The  circle  in  Figure  4  has  three  main  components:  the  problem  entity,  the 
conceptual  model,  and  the  computerized  model.  The  first  component  is  the  problem 
entity.  Sargent  (2007)  calls  this  component  the  “system”  in  future  updates  of  his  paper. 
He  describes  the  system  as  “real,  proposed,  idea,  situation,  policy,  or  phenomena  to  be 
modeled”  (Sargent  2007,  126).  The  next  component  of  the  circle  is  the  development  of 
the  conceptual  model.  It  is  the  model  developed  based  on  the  inputs  from  the 
stakeholders  of  their  understanding  of  the  system.  The  final  component  of  the  circle  is  the 
computerized  model.  The  computerized  model  is  programmed  based  on  the  CoM  to  run  a 
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simulation  on  a  computer  (Sargent  1984).  There  are  V&V  aspects  between  each  of  the 
components.  V&V  is  discussed  in  further  detail  later  in  the  chapter. 


Figure  4.  The  Original  Sargent  Circle 


Source:  Sargent,  Robert.  1984.  “A  Tutorial  on  Verification  and  Validation  of  Simulations 
Models.”  Proceedings  of  the  1984  Winter  Simulation  Conference,  116. 


b.  Evolved  Sargent’s  Model  Development  Processes 

Sargent  (2001)  updated  his  simplified  modeling  process  and  presented  it  to  the 
American  Society  of  Mechanical  Engineers.  The  updated  model  is  referred  as  the 
“Evolved  Sargent’s  Circle”  (Turner  2014,  32).  The  term  “Evolved  Sargent’s  MDP”  is 
used  in  this  dissertation  to  demonstrate  the  application  of  the  Evolved  Sargent’s  Circle  as 
a  MDP.  Figure  5  is  an  example  of  the  Evolved  Sargent  MDP  presented  during  the  2001 
Winter  Simulation  Conference.  The  updated  model  depicts  two  worlds,  the  real  world 
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and  the  simulation  world.  The  real  world  shows  a  system  subjected  to  experimentation. 
The  analysts  have  hypothesized  and  abstracted  ideas  of  the  system  based  on  system  the 
system  need  and  expected  results  to  address  the  need.  The  design  process  of  creating  the 
functional,  physical  and  allocated  architecture  decomposes  the  system  based  the  system 
theories  from  the  real  world.  These  ideas  are  then  turned  into  theories  regarding  the 
performance  and  the  expected  effects  the  system  will  produce.  The  system  enters  the 
simulation  world  with  the  established  theories  to  begin  construction  of  the  COM.  The 
completed  COM  is  then  validated  to  ensure  it  reasonably  matches  the  systems  theories 
(Sargent  2010). 

The  next  component  of  the  evolved  MDP  is  the  simulation  model  specification. 
The  products  of  the  CoM  are  the  objectives  for  the  simulation  (Sargent  2010).  This  is  the 
description  of  the  software  design  and  where  the  specification  of  the  simulation  model  is 
verified.  The  simulation  is  executed  once  the  specifications  have  been  verified.  The 
simulation  is  the  execution  of  the  CoM  developed  earlier  based  on  system  theories.  The 
results  of  the  simulation  are  the  basis  for  validation  of  the  model  of  the  system.  The 
evolved  circle  is  much  more  detailed  but  the  general  ideas  are  the  same. 
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Figure  5.  Real  World  and  Simulation  World  Relationship  with  Verification 

and  Validation 


s 


Implementation 

Verification 


Source:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying  and 
Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation  Conference , 
109. 


2.  Conceptual  Models 

Sargent  states  that  a  CoM  is  “the  mathematical/logical/verbal  representation  of  the 
problem  entity  (system)”  (Sargent  2010,  169).  The  CoM  is  the  first  model  to  be  built  in  a 
MDP.  It  is  built  early  in  the  MDP  to  identify  and  correct  any  deficiencies  before  using 
more  resources  throughout  the  development  process.  This  research  has  not  found  a 
structured  methodology  on  building  a  CoM.  There  also  is  a  lack  of  understanding  of  how 
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to  achieve  a  “good”  CoM.  Teeuw  and  van  den  Berg  (1997)  presented  general  criteria  for 
development  of  CoMs  quoted  here: 

•  Completeness:  The  concepts  must  be  expressive  enough  to  capture  all 
“essential  aspects”  of  the  real  world. 

•  Inherence  (propriety):  The  concepts  should  be  straight  to  the  point  and 
focus  on  essential  aspects  only. 

•  Clarity:  A  designer  must  be  able  to  comprehend  the  concepts  and  rules,  as 
well  as  be  able  to  apply  them  in  models  without  spending  too  much  time 
and  effort  (subjective) 

B.  VERIFICATION  AND  VALIDATION 

1.  Verification 

As  discussed  previously,  models  are  a  representation  of  the  system.  To  ensure  that 
the  models  are  credible  representation  of  the  system,  they  must  be  verified  and  validated. 
A  credible  model  will  assist  in  answering  whether  the  results  of  the  models  are  accurate 
depictions  of  the  system.  A  validated  model  is  also  important  because  the  information 
gained  from  the  model  is  used  by  DMs  to  make  decisions.  DMs  must  have  the  confidence 
that  the  results  of  the  model  are  correct  to  make  decisions  that  affects  the  entire 
organization. 

The  DOD  Standard  Practice  Document  MIL-STD-3022  (2008)  defines 
verification  as,  “The  process  of  determining  that  a  model,  simulation,  or  federation  of 
models  and  simulations  implementations  and  their  associated  data  accurately  represents 
the  developer’s  conceptual  description  and  specifications”  (10).  In  the  computer  science 
(CS)  domain,  it  “is  ensuring  that  the  computer  program  of  the  computerized  model  and 
its  implementation  is  correct”  (Sargent  2010,  166).  Verification  of  the  model  is  generally 
understood,  as  the  focus  was  on  ensuring  that  the  model  was  built  correctly.  The  CS 
interpretation  is  used  to  ensure  that  there  are  no  bugs  in  the  program  and  each  line  of 
code  executes  as  intended.  Verification  is  an  important  way  to  ensure  that  each  of  the 
system  components  performed  as  expected  during  the  tracing  of  effects  to  the  objectives 
of  the  NOS. 
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2. 


Validation 


Non-observable  systems  present  unique  challenges  to  the  validation  process.  The 
MIL-STD-3022  defines  validation  as 

the  process  of  determining  the  degree  to  which  a  model,  simulation,  or 
federation  of  models  and  simulations,  and  their  associated  data  are 
accurate  representations  of  the  real  world  from  the  perspective  of  the 
intended  use(s)  (Department  of  Defense  2008,  2). 

Validation  answers  the  question  of  the  accuracy  of  the  model  (Sokolowski  and 
Banks  2009).  Numerous  validation  techniques  are  well  documented  in  literature.  Over  77 
V&V  techniques  can  be  applied  for  two  major  stages  in  the  modeling  process  (Balci 
1986).  Sargent  (2013)  lists  15  validation  techniques  in  his  most  recent  paper.  Sokolowski 
and  Banks  (2009)  list  1 1  in  their  modeling  and  simulation  books.  All  those  validation 
techniques  can  be  grouped  into  two  major  types  of  validation:  subjective  and  objective. 
Objective  validation  is  the  use  of  mathematics  or  statistics  to  validate  the  model. 
Subjective  validation  is  relying  on  non-numerical  methods  to  validate  the  model,  such  as 
face  and  trace  validation  techniques.  Many  times,  a  combination  of  objective  and 
subjective  validation  techniques  are  used. 

Sargent  (2010)  states  that  a  model  is  considered  valid  if  the  model’s  accuracy  is 
within  an  acceptable  range  established  by  the  stakeholders.  The  model’s  accuracy  is 
measured  by  its  results;  thus,  it  is  important  to  identify  the  variables  early  in  the 
development  process.  As  we  revisit  the  Evolved  Sargent  Circle,  validation  occurs  early 
on  with  CoM  validation  and  ends  with  operational  validation. 

CoM  validation  is  the  demonstration  that  the  conceptual  ideas  that  are  the  bases  for 
the  CoM  are  accurate  representations  of  the  real  world  theories  of  the  system  and  the  models 
representing  the  system  “are  reasonable  for  the  purpose  of  the  model”  (Sargent  2010,  173). 
Many  times  the  face  validation  technique  is  an  appropriate  choice  for  CoM  validation.  Face 
validation  is  using  SMEs  or  individuals  who  have  knowledge  about  the  system  to  address 
whether  the  model  adequately  represents  the  system  in  the  real  world.  The  SMEs  normally 
require  the  use  of  flowcharts  or  graphical  models  (Sargent  1986),  or  a  set  of  model  equations. 
This  technique  is  known  as  traces.  Traces  validation  is  tracking  the  system  through  each  of 
the  components  to  the  overall  model  to  determine  if  the  model  is  correct. 


19 


Appleget,  Blais,  and  Jaye  (2013)  present  the  importance  of  the  development  of  the 
COM  to  “provide  the  developer’s  interpretation  of  what  is  needed  to  achieve  the  user’s 
objectives”  (Appleget,  Blais  and  Jaye  2013,  5).  They  state  that  three  essential  items  are 
needed  for  a  model  to  be  validated:  the  CoM,  a  referent,  and  the  description  of  the  data. 
The  CoM  is  previously  defined.  The  referent  is  the  laws  or  science  theories  that  will  be 
used  to  model  the  system.  The  description  of  the  data  is  needed  to  ensure  that  the  model 
has  the  required  collection  of  data.  These  three  items  are  known  as  the  “validation 
triangle”  and  are  part  of  another  model  development  process.  Figure  6  depicts  how  the 
validation  triangle  fits  into  the  overall  model  development  process. 


Figure  6.  Validation  Triangle 
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Source:  Appleget,  Jeffrey,  and  Blais,  Curtis,  and  Jaye,  Michael.  2013.  “Best  Practices  for 
US  Department  of  Defense  Model  Validation:  Lessons  Learned  from  Irregular  Warfare 
Models.”  Journal  of  Defense  Modeling  and  Simulation:  Applications,  Methodology, 
Technology ,  3. 
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An  operational  validation  is  conducted  to  determine  if  the  results  of  the  model 
sufficiently  represent  the  results  of  the  actual  system  and  its  applications.  If  the  model  is 
determined  not  to  represent  the  system  sufficiently,  analysts  must  be  able  to  retrace  the 
model’s  behavior  to  identify  what  caused  the  deviation.  Analysts  can  use  analytical 
methods  to  identify  the  cause  to  find  the  deviation  and  objectively  validate  the  model.  If 
analytical  methods  are  not  possible,  subjective  methods  can  be  used  to  validate  the 
model. 

C.  SYSTEM 

A  system  is  understood  as  an  integrated  set  of  elements  that  accomplish  defined 
common  objectives  (Parnell,  Driscoll,  and  Henderson  2011).  A  system  can  consist  of  a 
wide-ranging  set  of  elements,  such  as  people,  organization,  facilities,  procedures, 
collection  of  hardware  and  software  (Buede  2009).  Parnell,  Driscoll  and  Henderson 
(2011)  outline  key  attributes  of  a  system  as  the  following  quoted  here: 

•  Have  interconnected  and  interacting  elements  that  perform  systems 
functions  to  meet  the  needs  of  consumers  for  products  and  services. 

•  Have  objectives  achieved  by  system  functions. 

•  Interact  with  their  environment;  thereby,  creating  effects  on  stakeholders. 

•  Require  systems  thinking  that  uses  SE  throughout  process. 

•  Use  technology  developed  by  engineers  from  all  engineering  disciplines. 

•  Have  a  systems  life  cycle  containing  elements  of  risk  that  are  (a)  identified 
and  assessed  by  systems  engineers,  and  (b)  managed  throughout  this  life 
cycle  by  engineering  managers. 

•  Require  systems  decisions,  analysis  by  systems  engineers,  and  decisions 
made  by  managers  (3). 

It  is  important  to  understand  that  the  elements  of  an  organization  are 

interconnected  and  interact  with  each  other  to  support  the  organizational  system.  The 

organization  provides  services  to  achieve  defined  objectives  executed  by  its  functions.  By 

providing  services,  the  organization  must  interact  with  the  environment.  This  interaction 

creates  effects  that  the  stakeholders  must  understand  to  make  future  decisions  about  the 

organization  and  its  processes.  Thus,  analysts  use  the  systems  thinking  approach  to 
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identify  the  critical  system  structure  that  will  affect  its  interaction  with  the  environment. 
New  technology  from  a  wide-ranging  engineering  discipline  may  be  introduced  to  assist 
with  the  interaction  or  the  decision-making  process.  A  system  life  cycle  process  will  be 
used  to  guide  the  system  from  conception  to  retirement  and  ensures  that  the  objectives  of 
the  system  are  met  throughout  the  entire  life  of  the  system.  Using  the  attribute  list  as  a 
guide,  it  is  possible  to  begin  the  SE  process. 

D.  OBSERVABLE  AND  NON-OBSERVABLE  SYSTEMS 

The  determination  of  which  objective  or  subjective  validation  techniques  is 
necessary  depends  on  whether  the  system  is  observable  or  non-observable.  Robert 
Kalman  (1959)  originally  defined  for  dynamic  systems  as  “If  a*-  is  not  an  observable 
costate,  then  the  state  x;  cannot  be  determined;  in  other  words  the  plant’s  (system’s) 
behavior  cannot  be  inferred  from  the  measurements”  (486).  Dahleh,  Dahleh  and 
Verghese  (2011)  further  described  an  observable  system  as,  “The  initial  state  x(0)  can  be 
uniquely  determined  from  the  input  and  output  measurements  if  the  system  is 
observable.”  Figure  7  graphically  shows  the  determination  of  observable  systems  and 
NOSs  as  defined  in  the  domain  of  control  theory.  Thought  bubbles  are  added  to  compare 
each  component  of  the  figure  to  the  M&S  domain.  Figure  7  presents  a  system  with  an 
unknown  initial  state.  The  inputs  of  the  system  are  executed  and  outputs  are  produced.  If 
the  initial  state  of  the  system  can  be  determined,  then  the  system  is  classified  as 
observable.  It  is  classified  as  non-observable  if  a  determination  cannot  be  made. 
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Figure  7.  Overview  of  Observable  and  Non-Observable  Classification 


1.  Observable  Systems 

Sargent  (2010)  defines  observable  system,  “as  it  is  possible  to  collect  data  on  the 
operational  behavior  of  the  problem  entity  during  the  execution  of  a  simulation”  (174). 
For  observable  systems,  analysts  are  able  to  observe  the  behavior  of  the  system  during 
the  operation  of  the  model  and  evaluate  the  system  throughout  its  execution.  A  physics- 
based  model,  such  as  a  small  unit  force  on  force  lethal  engagement,  can  use  laws  of 
physics  as  its  referent  to  forecast  the  behavior  of  the  system  and  there  is  very  little  to  no 
deviation  from  the  expected  effects  to  actual  effects.  If  there  are  deviations,  analysts  can 
refer  back  to  the  original  equations  to  identify  any  deficiencies.  In  such  cases,  the  referent 
is  implicit.  The  referent  comes  from  the  laws  that  have  been  used  to  represent  past 
combat  (Appleget ,  Blais,  and  Jaye  2012). 

2.  Non-Observable  Systems 

A  NOS  is  the  opposite  of  the  observable  system  where  it  is  not  possible  to  collect 
data  on  the  operational  behavior  of  the  problem  entity.  It  is  difficult  to  assess  the  quality 
of  the  model  because  there  is  not  enough  information  about  the  system  to  understand  its 
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behavior  fully.  This  is  especially  true  for  models  of  systems  that  are  nonexistent  or  in 
development  for  future  operations.  The  quality  assurance  of  the  model  is  still  a  challenge 
even  for  existing  systems  that  are  not  completely  observable  (Balci  1986). 

The  definition  of  a  NOS  in  the  M&S  domain  is  not  clear.  Turner  (2014)  described 
NOSs  as  systems  that  do  not  facilitate  the  collection  of  data.  In  order  to  provide  an 
example,  Turner  (2014)  uses  an  anti -piracy  operation  scenario  as  an  example  of 
simulating  a  NOS.  He  identifies  in  the  scenario  that  there  is  sufficient  knowledge  of  the 
units  conducting  the  operation.  The  uncertainty  of  the  behavior  of  the  pirates  is  too  great 
to  build  a  model  to  examine  the  results  of  the  interaction  (Turner  2014).  Thus,  there  is  a 
need  for  a  non-traditional  approach  to  modeling  a  NOS  to  overcome  the  uncertainty. 

A  future  conceptual  system  can  be  classified  as  a  NOS  due  to  the  lack  of 
information  about  its  components.  It  can  be  a  current  system  where  the  interactions 
between  the  components  are  not  observable.  Examples  provided  in  the  most  recent 
literature  about  a  NOS  are  of  non-physics-based  systems  interactions  with  external 
systems. 

3.  Validation  of  Observable  and  Non-Observable  Systems 

Sargent  (2007)  suggests  that  a  NOS  can  be  operationally  validated  using  two 
different  approaches,  subjective  or  objective.  Table  1  outlines  Sargent’s  approaches  to 
operational  validity  for  NOSs.  The  objective  approach  cannot  be  used  because  for  future 
conceptual  systems,  there  are  no  other  models  to  compare.  In  addition,  with  no  data, 
statistical  tests  are  meaningless.  Even  in  the  subjective  approach,  there  would  be  no 
comparison  to  other  models.  Thus,  the  only  method  of  operational  validity  of  a  NOS  is 
through  model  exploration. 
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Table  1 .  Operational  Validity  Classification  for  Non-Observable  Systems 


Non-Observable  System 

Subjective 

Approach 

•  Explore  Model  Behavior 

•  Comparison  to  Other  Models 

Objective 

Approach 

•  Comparison  to  other  Models 

Using  Statistical  Tests 

Sargent,  Robert.  2007.  “Verification  and  Validation  of  Simulation  Models.”  Proceedings 
of  the  2007  Winter  Simulation  Conference :  130. 


An  observable  system  also  uses  objective  validation  techniques  for  validation.  An 
operational  validation  for  an  observable  system  is  achieved  when  the  outputs  match  the 
expected  output  that  supports  the  fundamental  objective.  For  a  NOS,  the  outputs  do  not 
match  the  expected  outputs.  Therefore,  in  a  NOS,  the  COM  is  evaluated  to  conduct 
model  exploration. 

The  model  of  the  system  is  determined  to  be  a  failure  after  multiple  iterations  of 
the  simulation  and  never  meets  the  expected  output.  The  model  may  never  converge  to 
determine  the  initial  state  of  the  system  due  to  not  knowing  which  function  prevents 
outputs  from  matching  the  expected  output.  Buede  (2009)  describes  the  failure  of  a 
system  is  determined  when  the  process  is  also  not  observed  and  the  system  does  not 
maintain  a  copy  of  its  requirements.  A  point  of  fault  cannot  be  determined  and  a  new 
system  must  be  created  to  address  the  deficiencies. 

E.  SYSTEMS  ENGINEERING 

Buede  (2009)  defines  systems  engineering  as  “engineering  discipline  that 
develops,  matches,  and  trades  off  requirements,  functions,  and  alternate  system  resources 
to  achieve  a  cost-effective,  life-cycle-balanced  product  based  upon  the  needs  of  the 
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stakeholders”  (10).  There  are  eight  functions  listed  by  Buede  (2009)  quoted  here  as  an 
overview  of  the  complete  SE  process: 

0a  Define  the  problem  to  be  solved 

Ob  Define  and  evaluate  alternate  concepts  for  solving  problem 

1 .  Define  the  system-level  design  problem  being  solved 

2.  Develop  the  system  functional  architecture 

3.  Develop  the  system  physical  architecture 

4.  Develop  the  system  allocated  architecture 

5.  Develop  the  interface  architecture 

6.  Define  the  qualification  system  for  the  system  (51). 

This  research  uses  the  last  six  functions  to  investigate  the  concept  of  non¬ 
observable  systems  and  to  build  its  architecture. 

1.  Systems  Engineering  Process 

A  system  simply  does  not  appear,  as  it  goes  through  a  methodical  SE  process  to 
ensure  that  the  system  works  and  meet  the  stakeholders’  needs.  A  very  important  aspect 
of  SE  is  its  relationship  to  the  system  life  cycle.  There  are  many  examples  of  systems  life 
cycle  models  in  literature,  but  the  most  common  aspects  are  conceptual  design, 
development,  production,  training,  operations  and  maintenance,  refinement,  and 
retirement. 

SE  is  multidisciplinary  in  the  fact  that  it  involves  the  integration  of  knowledge 
and  best  practices  from  different  disciplines  into  the  development  and  an  interconnected 
and  interrelated  system.  The  engineering  of  integrating  these  components  and  ensuring 
that  the  system  meets  the  needs  of  the  stakeholders  is  what  makes  SE  unique  from  other 
engineering  disciplines. 

INCOSE  notes  that  the  SE  process  has  an  iterative  nature  that  supports  learning 
and  continuous  improvement  (SE  Handbook  Working  Group  2011).  It  is  during  the 
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engineering  process  that  the  analysts  gain  a  better  understanding  of  the  stakeholders’ 
needs  and  apply  this  knowledge  to  the  design  and  the  functionality  of  the  system.  The 
analyst  may  discover  unexpected  or  emergent  properties  as  the  system  performs  its 
functions  and  interacts  with  its  elements,  external  systems,  and  environment.  This  can  be 
attributed  to  the  complexity  of  the  system.  By  using  the  SE  process,  analysts  are  able  to 
develop  the  design  and  integrate  the  components  to  create  an  effective  system  that 
enables  the  public  to  trust  the  banking  system  and  continue  to  deposit  their  money  at  their 
local  banks. 

One  of  the  standards  that  analysts  use  is  the  military  standard  499B  (1993),  as  it 
defines  the  engineering  of  systems  as  “an  interdisciplinary  approach  encompassing  the 
entire  effort  to  evolve  and  verify  an  integrated  and  life  cycle  balanced  set  of  system 
people,  product,  and  process  solutions  that  satisfy  customer  needs”  (Department  of 
Defense  1993,  40).  In  the  technical  draft,  quoted  below,  it  states  that  SE  encompasses  the 
following: 

•  Technical  efforts  related  to  the  development,  manufacturing,  verification, 
deployment,  operations,  support,  disposal  of,  and  user  training  for  system 
products  and  processes 

•  The  definition  and  management  of  the  system  configuration 

•  The  translation  of  the  system  definition  into  work  breakdown  structures 

•  The  development  of  information  for  management  decision  (Department  of 
Defense  1993,  40) 

The  SE  process  has  key  concepts  that  must  be  reviewed  to  design  a  NOS.  Each 
concept  is  a  building  block  for  designing  overall  systems  architecture  of  a  NOS. 

Buede  (2009)  defines  operational  concept  as  a  “vision  for  what  the  system  is  (in 
general  terms),  a  statement  of  mission  requirements,  and  a  description  of  how  the  system 
will  be  used”  (481).  The  operational  concept  provides  an  overall  view  of  how  the  system 
will  interact  with  the  external  system.  A  military  example  of  an  operational  concept 
would  be  the  purpose  of  a  military  mission  and  how  it  will  interact  with  the  enemy  or 
local  populous.  An  external  systems  diagram  establishes  the  boundaries  of  the  system  and 
the  external  systems  with  which  it  may  interact.  Objectives  hierarchy  is  the  hierarchical 
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list  of  objectives  that  must  be  met.  The  hierarchy  is  based  on  the  requirements  and  values 
of  the  stakeholders.  Requirements  are  defined  as  the  tasks  that  must  be  completed  to  meet 
the  stakeholders’  needs.  Functions  are  the  action  that  the  system  performs  to  produce  the 
intended  effects,  and  they  serve  as  the  foundations  of  building  a  functional  architecture, 
which  is  discussed  in  more  detail  later  in  this  chapter.  Items  are  the  inputs  that  go  into  the 
system.  Components  are  the  physical  aspect  of  the  system.  It  is  the  physical  items  that 
perform  the  functions.  Interfaces  are  where  components  and  systems  are  connected.  It  is 
the  location  where  components  and  systems  interact  with  each  other.  It  is  in  these  spots 
where  observations  may  not  happen  during  initial  testing  of  a  system. 

2.  The  Vee  Model 

There  have  been  several  different  processes  developed  to  assist  with  engineering  a 
system.  Figure  8  shows  the  “Vee”  process,  which  describes  SE  as  being  composed  of 
decomposition  of  a  system  followed  by  the  integration  to  improve  the  system.  The  left 
side  of  the  Vee  is  the  decomposition  of  the  system  that  presents  three  phases  of 
understanding  the  requirements,  developing  the  system  performance  specification  and 
system  validation  plan,  and  expanding  the  performance  specifications  into  a 
configuration  item  verification  plan.  Decomposition  is  the  “hierarchical,  functional  and 
physical  partitioning  of  any  system  into  hardware  assemblies,  software  components,  and 
operator  activities  that  can  be  scheduled,  budgeted,  and  assigned  to  a  responsible 
manager”  (Forsberg,  Moos,  and  Cotterman  2005,  110).  The  Vee  model’s  focus  on 
decomposition  and  design  is  to  improve  the  understanding  of  the  operational  needs  and 
translate  it  to  system-level  requirements  (Buede,  2009).  Also,  note  that  the  decomposition 
is  conducted  from  the  overall  system  to  subsystems  to  entity  levels.  It  is  through  this 
decomposition  that  the  system  can  be  identified  to  its  entities  to  correct  errors  and  fill 
gaps. 
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Figure  8.  The  SE  “Vee”  Model 


Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons,  10. 


The  horizontal  line  shows  where  the  analysts  mentioned  earlier  take  the 
requirements  and  produce  the  physical  aspects  of  the  system  (Buede,  2009).  The 
conceptual  model  of  the  system  developed  on  the  decomposition  side  of  the  Vee  is  the 
“blue  print”  the  other  analysts  will  follow  to  develop  a  physical  system  and  begin  its 
integration.  As  mentioned  previously,  the  conceptual  model  must  be  created  with  limited 
errors  and  gaps  filled  to  reduce  the  overall  cost  of  creating  the  system. 

The  right  side  of  the  Vee  is  the  integration  and  verification  of  the  system.  This  is 
where  the  system  is  put  together  from  its  entities  to  sub-systems  to  the  overall  system. 
The  system  is  tested  to  ensure  that  all  of  the  elements  are  in  compliance  and  meet  the 
stakeholders’  satisfaction. 
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3. 


The  Waterfall  Model 


The  waterfall  model  developed  by  Dr.  Winston  W.  Royce  is  another  widely 
accepted  SE  model.  As  seen  in  Figure  9,  the  waterfall  is  a  linear  model  that  is  very  risk 
adverse  (Forsberg,  Mooz,  and  Cotterman  2005,  106).  Unlike  the  Vee,  the  waterfall  is 
easier  to  understand  due  to  its  simplicity.  This  simplicity  makes  the  waterfall  lacks  some 
important  aspects  of  SE,  such  as  the  integration  of  specialists  to  create  the  model  of  the 
physical  system  for  integration,  verification,  and  validation.  The  waterfall  is  a  linear  path 
from  top  to  bottom  from  the  system  requirements  phase  to  operations  and  maintenance.  It 
leaves  little  opportunity  to  introduce  new  ideas  during  the  development  process.  The 
waterfall  does  allow  changes  by  conducting  a  backward  iteration  to  change  its  baseline. 
Because  the  model  emphasizes  the  flow  down  of  progress,  going  backward  is  not  cost 
effective  and  it  is  difficult  to  repeat  steps. 


Figure  9.  The  Waterfall  Model 


Source:  Royce,  Winston  W.  1970.  “Managing  the  Development  of  Large  Software 
Systems.”  Proceedings  of  IEEE  WESCON ,  329. 
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4. 


The  Spiral  Model 


The  spiral  model  was  created  to  improve  on  the  developments  of  the  waterfall 
model  and  to  improve  the  process.  The  spiral,  unlike  the  linear  waterfall,  as  the  name 
attests  is  non-linear  and  emphasizes  repeatability  during  its  development  process.  Figure 
10  shows  the  spiral  model  presented  by  Boehm  (1988).  In  Boehm’s  model,  each  spiral  is 
in  essence  an  iteration  of  the  waterfall  model  (Parnell,  Driscoll,  and  Henderson  2011). 
The  spiral  also  introduces  the  concept  of  risk  analysis  throughout  its  cycle.  The  system 
must  successfully  mitigate  identified  risks  at  each  phase  to  move  on  to  the  next  phase. 
Failure  to  resolve  any  risks  can  lead  to  delays  or  even  termination  of  the  overall  system. 


Source:  Boehm,  Berry  W.  1988.  “A  Spiral  Model  of  Software  Development  and 
Enhancement.”  Computer ,  64. 
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The  three  SE  process  models  all  present  different  ways  to  develop  a  system. 
However,  they  all  share  the  characteristics  of  identifying  requirements,  design, 
development,  maintenance,  and  retirement.  Although  the  analyst  is  involved  in  all  the 
phases  during  the  SE  process,  the  design  phase  is  where  they  are  mostly  involved. 

F.  SYSTEMS  DESIGN 

Buede  (2009)  describes  system  design  as  transforming  stakeholders’  ideas  of 
systems  into  visual  models  by  engineers.  Designing  a  system  requires  several  steps.  A 
system  is  decomposed,  requirements  identified,  and  the  architectural  representation  of  the 
system  created  (Buede  2009).  Turner’s  (2014)  research  identified  that  designing  models 
of  NOSs  for  simulation  needed  more  research  into  the  proper  development  of  its 
structure. 

Blanchard  and  Fabry cky  (2010)  explain  that  the  basis  of  establishing  the  structure 
of  a  system  starts  with  the  design  of  the  system.  The  design  is  an  analyst’s  vision  of  how 
the  system  will  meet  the  requirements  identified  by  the  stakeholders  (Blanchard  and 
Fabrycky  2010).  The  design  of  a  system  takes  form  as  early  as  the  initial  interaction 
between  the  stakeholders  and  the  analyst.  The  initial  design  is  not  the  final  design  and  the 
traceability  of  its  effects  to  the  objectives. 

Figure  1 1  illustrates  the  importance  of  ensuring  a  well-designed  system  early  in 
the  life  cycle  process.  The  X-axis  represents  the  life  cycle  phases  and  the  Y-axis 
represents  the  percent  of  the  cost  of  developing  the  system.  The  programmed  cost  of  the 
cost  committed  curve  has  a  steady  increase  to  100%  while  the  actual  cost  incurred 
displays  a  steep  rise  during  the  construction  and  production  phase.  At  the  end  of  the 
“detailed  design  and  integration”  phase,  the  cost  committed  is  at  80%  while  the  incurred 
cost  is  only  20%.  Ensuring  that  the  system’s  functions,  components,  and  interfaces  are 
clearly  defined  and  are  traceable  to  the  requirements  outlined  by  the  stakeholders  is 
important  to  ensuring  that  costs,  no  matter  how  it  is  defined,  are  reduced  for  developing  a 
system. 
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Figure  11.  Systems  Life  Cycle  versus  Cost 


Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons,  8. 


The  systems  cost  curve  is  also  in  line  with  Sargent’s  model  of  cost  versus  value  as 
seen  in  Figure  12.  As  the  confidence  in  the  model  increases,  both  the  value  and  the  cost 
also  increase  (Sargent  2010).  However,  examining  the  cost  and  value  curves,  the  two 
curves  intersect,  which  indicates  the  return  on  the  cost  is  not  worth  the  value  of  the 
model.  Sargent  (2010)  states  that  the  cost  of  the  model  may  not  justify  the  attempt  for 
absolute  validation  of  a  model.  Thus,  improving  the  methods  of  existing  validation 
methods  are  ways  to  ensure  that  the  cost  of  the  model  meets  the  values  of  the 
stakeholders. 
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Figure  12.  Confidence  that  Model  Is  Valid 


Cost 


Source:  Sargent,  Robert.  2007.  “Verification  and  Validation  of  Simulation  Models.” 
Proceedings  of  the  2007  Winter  Simulation  Conference ,  125. 


A  well-designed  conceptual  model  will  improve  the  structure  to  ensure  that  the 
effects  of  the  system  are  traceable  and  support  the  validation  of  the  NOS.  Using  the  Vee 
model  discussed  earlier,  the  design  phase  is  primarily  focused  on  the  left  side  or  the 
decomposition  side  of  the  Vee  model.  Architecting  is  an  important  aspect  of  system 
design.  Architecting  techniques  are  used  to  decompose  the  system  into  functions, 
components,  and  allocation.  The  next  section  provides  an  in-depth  review  of  architecting. 
The  right  side  of  the  model  describes  the  integration  and  the  qualification  of  the  system. 
During  this  phase,  the  model  of  the  system  goes  through  the  verification  and  validation 
phase  to  ensure  that  the  system  design  decomposed  on  the  left  side  supports  the  defined 
requirements. 

G.  SYSTEMS  ARCHITECTING 

The  term  architecture  has  traditionally  been  related  to  physical  buildings.  It  is  the 
way  people  have  been  designing  and  constructing  structures  throughout  history.  Systems 
engineers  have  borrowed  architecting  concepts  to  solve  the  difficulties  of  designing 
complex  systems  (Maier  and  Rechtin  2000).  Architecting  is  a  way  for  analysts  to 
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decompose  the  system  to  translate  the  needs  of  the  stakeholders  and  the  solutions  of  how 
the  systems  will  satisfy  the  needs.  During  the  design  phase,  or  the  left  side  of  the  Vee 
model,  three  types  of  architectures,  the  functional,  physical,  and  allocated,  are  used  for 
the  decomposition  process  (Levi  1993).  Figure  13  depicts  Levi’s  (1993)  architecture 
development  model  as  outlined  by  Buede.  The  architectural  development  process  starts 
with  the  operational  concept.  Buede  describes  the  operational  concept  as  an  overview  of 
the  system.  The  operational  concept  describes  the  mission,  requirements,  and  the 
execution  of  the  system.  Functional,  physical,  and  allocated  architectures  are  developed 
as  part  of  the  decomposition  of  the  system  (Buede  2009).  The  functional  architecture 
describes  what  the  system  will  do.  The  physical  architecture  depicts  what  components  are 
available  in  the  system.  The  allocated  architecture  is  the  mapping  of  functions  to 
components  (Buede  2009).  It  is  important  that  all  three  of  these  models  are  developed 
independently  to  identify  the  functions  and  the  components  that  perform  the  functions  to 
integrate  the  two  architectures. 


Figure  13.  Architecture  Development  in  the  Engineering  of  a  System 


Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons,  28. 
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Architecting  is  an  important  tool  the  analyst  will  use  to  decompose  the  NOS  to 
allow  traceability  of  the  effects.  The  combination  of  the  architectures  helps  to  answer 
which  component  with  which  functions  had  the  greatest  impact  on  the  results  of  the 
system. 


1.  Functional  Architecture 

The  Merriam-Webster  dictionary  defines  the  term  function,  “as  the  special 
purpose  or  activity  for  which  a  thing  exists  or  is  used”  (Merriam-Webster  2015).  For  our 
purposes,  it  is  possible  to  substitute  the  word  “thing”  with  system.  It  is  what  the  system 
will  perform  at  its  basic  definition.  A  more  comprehensive  definition  provided  by  the 
INCOSE  defines  the  term  function  as,  “A  characteristic  task,  action,  or  activity  that  must 
be  performed  to  achieve  a  desired  outcome”  (INCOSE  2003,  281).  Functions  may  be 
accomplished  by  one  or  more  components  of  the  “system  comprised  of  equipment 
(hardware),  software,  firmware,  facilities,  personnel,  and  procedural  data”  (INCOSE 
2003,  123).  Buede  (2009)  also  defines  the  term  function  as,  “a  process  that  takes  inputs  in 
and  transforms  these  inputs  into  outputs.”  Combining  INCOSE’s  and  Buede’s  definitions 
provides  a  robust  understanding  of  the  term  function.  A  function  is  when  a  system  takes 
inputs  in,  which  are  tasks,  actions,  or  activities,  and  the  output  should  be  the  desired 
system  behavior.  However,  when  the  output  of  the  function  deviates  from  the  desired 
system  behavior,  an  error  or  failure  may  occur.  In  the  fault-tolerance  community,  an  error 
is  determined  when  the  system  is  able  to  observe  the  changes  of  the  system.  Since  an 
error  is  observed,  it  can  be  identified  and  corrected.  However,  an  analyst  normally  is  not 
able  to  monitor  the  entire  state  continuously,  as  not  all  errors  are  able  to  be  observable, 
which  leads  to  system  failure.  A  failure  in  the  system  is  an  unobserved  deviation  from  the 
system  requirements.  Figure  14  depicts  a  concept  map  for  fault  tolerance  terms  as 
described  by  Buede. 
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Figure  14.  Concept  Map  for  Fault  Tolerance  Terms 


Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons,  243. 


A  functional  architecture  enables  the  analyst  to  organize  the  many  functions  the 
system  must  perform,  ft  does  this  by  decomposing  the  system’s  top-level  function  and 
outlining  what  they  system  must  do.  ft  is  the  functional  architecture  that  allows  the 
“hierarchical  arrangement  of  functions,  their  internal  and  external  functional  interfaces, 
their  respective  functional  and  performance  requirements,  and  the  design  constraints” 
(1NCOSE  2004,  124). 

The  functional  architecture  outlines  the  tasks  of  the  system.  One  of  the  ways  is 
with  a  model  of  a  functional  hierarchy  showing  the  functions  to  be  performed  by  the 
system  and  its  components  (Buede  2009).  Another  use  of  the  functional  architecture  is 
capturing  the  transformation  of  the  inputs,  outputs,  controls,  and  the  mechanisms  of  the 
system. 

To  build  a  functional  architecture,  an  analyst  must  perform  several  steps.  First,  the 
analyst  must  define  the  system’s  functions  by  conducting  a  functional  analysis.  A 
functional  analysis  is  conducted  to  identify  the  required  functions  of  the  system  and  its 
internal  and  external  interfaces,  ft  is  one  of  the  earliest  processes  to  be  performed  in  the 
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system  life  cycle.  There  are  several  methods  to  perform  functional  analysis.  The  output  of 
all  functional  analysis  is  the  identification  of  system  functions  and  interfaces  (Parnell 
Driscoll,  and  Henderson  2011).  Parnell,  Driscoll,  and  Henderson  (2011)  list  four  main 
functional  analysis  techniques:  Functional  hierarchy,  functional  flow  diagram,  IDEFO, 
and  modeling  and  simulations.  IDEFO  and  modeling  and  simulations  are  discussed  in 
more  detail  later  in  the  chapter. 

a.  Functional  Hierarchy 

A  functional  hierarch  provides  an  understanding  of  the  functions  that  the  system 
must  perform  from  top  to  bottom.  It  is  the  foundation  of  more  detailed  functional  analysis 
conducted  throughout  the  life  cycle  (Parnell  Driscoll,  and  Henderson  2011).  The 
functional  hierarchy  does  not  identify  interrelationships  between  system  components. 

b.  Functional  Flow  Diagram 

The  relationships  between  the  components  can  be  depicted  on  a  functional  flow 
diagram  (FFBD)  after  completing  the  functional  hierarchy.  Defining  all  of  the 
relationships  within  a  system  supports  a  detailed  functional  decomposition.  Figure  15  is 
an  example  of  a  FFBD  of  the  National  Aeronautics  and  Space  Administration’s 
(NASA’s)  Space  Transportation  System  (STS)  Flight  Mission  (Parnell,  Driscoll,  and 
Henderson  2011).  However,  the  limitation  of  the  functional  flow  diagram  is  the  inability 
to  identify  interfaces  of  the  components.  An  enhanced  functional  flow  block  diagram 
(EEFBD)  represents  three  critical  aspects  of  systems  modeling:  flow,  data  interactions 
and  resources.  An  EFFBD  is  a  variation  of  the  FFBD  that  also  represents  the  behavior  of 
a  system  (Buede  2009,  93). 
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Figure  15.  Functional  Decomposition  for  the  Top  Level  of  the  STS  Flight 

Mission 


Source:  Parnell,  Gregory  S.,  and  Driscoll,  Patrick  J.,  and  Henderson,  Dale  L.  2011, 
Decision  Making  in  Systems  Engineering  and  Management.  Hoboken,  NJ:  John  Wiley  & 
Sons,  321. 


c.  Integrated  Definitions  for  Functional  Modeling  0 

The  IDEFO  model  provides  the  alignment  of  functions  to  components.  The  IDEFO 

language  is  a  method  of  describing  the  system’s  processes  and  activities.  There  are  14 

methods  in  the  IDEF  suite.  IDEFO’s  purpose  is  for  modeling  functions.  IDEFO  is  a 

method  of  functional  decomposition  inputs,  controls,  outputs,  and  mechanisms  (ICOM) 

that  address  the  interaction  of  the  system  with  other  systems.  It  can  describe  the 
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hierarchical  functions  of  the  system  with  the  IDEFO  hierarchy,  and  starts  at  AO  with  the 
first  tier  functions  to  Al,  A2...Ai,  the  second  tier,  and  All,  A21...Aij,  the  third  tier 
functions  (Parnell,  Driscoll,  and  Henderson  2011).  The  IDEFO  models  are  used  to 
decompose  a  system  to  show  stakeholders  all  of  the  ICOMs  that  are  involved  in 
performing  a  function. 


Figure  16.  A  Generic  IDEFO  Model 


Inputs 


i 


Controls 


i 


Activity 


Mechanism 


Outputs 


Source:  Parnell,  Gregory  S.,  and  Driscoll,  Patrick  J.,  and  Henderson,  Dale  L.  2011, 
Decision  Making  in  Systems  Engineering  and  Management.  Hoboken,  NJ:  John  Wiley  & 
Sons,  44. 


Figure  16  shows  a  basic  building  block  of  an  IDEFO  model.  The  box  represents  a 
function  that  the  system  will  be  performing.  The  arrows  coming  down  from  the  top  represent 
the  controls  that  specify  the  conditions  needed  for  the  function  to  perform.  An  example  is  a 
rules  of  engagement  directive  in  Afghanistan.  It  dictates  how  military  personnel  react  to 
contact.  The  arrows  on  the  bottom  are  the  mechanism  that  performs  the  functions.  The 
identification  of  the  mechanism  to  the  function  is  important  to  creating  the  allocated 
architecture.  The  arrows  on  the  left  coming  into  the  box  are  the  inputs.  They  are  the  current 
state  prior  to  the  function  being  executed.  The  arrows  leaving  the  box  are  the  outputs  that  are 
transformed  as  a  result  of  the  execution  of  the  function.  The  outputs  may  also  be  an  input  to 
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other  functions  within  the  IDEFO  (Parnell,  Driscoll,  and  Henderson  201 1).  Figure  17  shows 
a  more  complex  IDEFO  model  of  an  elevator  system. 


Figure  17.  Elevator  System  External  Systems  Diagram  for  Operational  Phase 
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Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons,  58. 


2.  Physical  Architecture 

An  important  aspect  of  architecting  is  to  understand  which  components  will 
perform  the  functions  required  of  the  system,  which  can  be  achieved  by  the  development 
of  the  physical  architecture.  The  physical  architecture  of  a  system  is  the  description  of  the 
components  that  make  up  the  system  (Buede  2009).  It  is  hierarchical,  like  the  functional 
architecture  described  earlier,  and  helps  the  analyst  to  view  the  overall  system  down  to  its 
basic  components. 
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There  are  two  ways  to  view  physical  architecture,  generic  and  instantiated.  Figure 
18  is  a  generic  physical  architecture  of  an  elevator  from  Buede’s  elevator  case  study.  It 
depicts  the  components  that  make  up  the  elevator.  A  generic  physical  architecture 
outlines  the  hierarchy  of  the  components  of  the  system.  Instantiated  physical  architecture 
provides  a  more  detailed  description  of  the  components  to  enable  performance  modeling 
of  the  system. 


Figure  18.  Generic  Physical  Architecture  from  the  Elevator  Case  Study 
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A  morphological  box  is  one  way  to  assist  in  developing  the  physical  architecture. 
It  is  a  technique  using  a  matrix  to  list  the  components  of  the  system.  It  is  used  to  break 
down  a  system  into  segments  as  defined  by  the  generic  physical  architecture.  Then, 
details  about  the  components  are  filled  in  to  complete  the  matrix.  The  detailed  box 
becomes  the  instantiated  physical  architecture  (Buede  2009).  The  morphological  box 
allows  the  analyst  to  see  the  details  of  each  of  the  component  and  create  the  best 
combination  for  the  system.  For  instance,  the  example  shown  in  Table  2  is  of  a  vehicle 
needed  for  a  mission.  Components  of  the  vehicle  would  be  listed  on  top. 


Table  2.  Example  of  a  Morphological  Box  for  a  Vehicle 


Tire  Size 

Gas  Tank  Size 

Engine  Size 

16" 

lOgal 

4  Cylinder 

18" 

15  gal 

6  Cylinder 

20" 

8  Cylinder 

The  tire  size,  the  gas  tank,  the  engine  size  would  be  some  of  the  components  for 
consideration  of  a  vehicle.  Based  on  this  example,  there  would  be  3x2x3=54  different 
vehicle  combinations  to  consider.  A  real  world  consideration  for  a  vehicle  would  have 
many  more  combinations. 

3.  Allocated  Architecture 

The  final  piece  of  architecting  is  the  development  of  the  allocated  architecture. 
The  allocated  architecture  is  the  integration  of  the  functional  architecture  and  the  physical 
architecture  to  ensure  the  right  components  are  doing  the  right  functions.  It  also  defines 
how  the  system  will  interact  with  the  external  systems.  It  is  important  that  the 
architecture  meets  the  requirements  of  the  stakeholders  and  gains  their  approval.  The 
allocated  architecture  will  provide  the  overall  description  of  the  system. 

The  allocated  architecture  will  be  used  to  model  the  entire  system.  This 
architecture  will  provide  the  traceability  of  the  system  effects  to  its  objectives  for  NOSs. 


43 


Traceability  of  the  model  would  help  identify  the  cause  of  deviation  from  the  intended 
system  effects  and  actual  system  effects. 


H.  RECENT  MODELING  OF  NON-OBSERVABLE  SYSTEMS  FOR 
SIMULATIONS 

Turner’s  research  in  2014  is  the  one  of  the  first  known  work  on  modeling  of  a 
NOS  for  simulations.  Turner  (2014)  proposes  the  following  method  to  address  the  current 
gap  in  literature  of  an  approach  to  decompose  the  system,  identify  relationships  that 
impacts  the  system  in  a  traceable  and  defensible  manner. 

•  Utilize  SMEs  to  decompose  the  system  and  assign  impact  relationships 
between  measures 

•  Determine  importance  of  relationships  through  analysis 

•  Based  on  relationship  importance,  decide  how  the  entity  is  represented  and 
to  what  fidelity  based  on  a  selection  scheme 

•  Compare  results  to  impact  relationships  (Turner  2014,  105). 

As  mentioned  earlier  in  the  chapter,  decomposition  of  the  system  is  an  important 
aspect  of  the  SE  process.  SE  has  several  methods  of  decomposing  a  system.  The  two 
basics  are  functional  and  physical  decomposition  to  understand  what  functions  the  system 
will  perform  and  which  component  will  perform  them. 

Turner  (2014)  uses  a  mathematical  graph  presented  by  Green  (2001)  during  a 
Military  Operations  Research  Society  (MORS)  on  measures  of  effectiveness  for 
command  and  control.  The  approach  uses  a  mathematical  graph  to  show  the  different 
levels  of  a  system.  The  top  level  is  the  objective.  The  objective  defines  the  purpose  of  the 
system  and  the  desired  behavior.  The  following  level  is  the  effects  level.  It  is  defined  as 
the  measurement  of  how  the  system  performs  within  a  larger  system.  The  level  below  is 
performance.  Performance  measures  the  individual  components  tasks,  e.g.,  range  and 
speed.  The  final  level  is  the  performance  parameters.  It  is  the  characteristics  of  the 
system,  such  as  the  weight  of  the  vehicle  and  the  wingspan  of  an  airplane.  Turner  (2014) 
points  out  that  the  impact  travels  from  the  lowest  level  of  technical  performance  to  the 
highest  level,  the  objective.  Figure  19  outlines  the  different  levels  and  the  flow  of  impact. 
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The  mathematical  graph  identifies  the  levels  as  the  nodes  that  represent  the  metrics,  while 
the  edges  represent  the  relationship  between  the  two  levels. 


Figure  19.  System  Decomposition  Graph 
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Source:  Turner,  Andrew.  2014.  “A  Methodology  for  the  Development  of  Models  for 
Simulation  of  Non-Observable  Systems.”  PhD  diss.,  Georgia  Institute  of  Technology, 

107. 

As  we  follow  the  edges  beginning  with  Tl,  it  may  have  an  impact  on  the 
performance  of  PI.  The  performance  measured  at  PI  may  impact  the  effects  at  El. 
Finally,  the  effects  at  El  may  have  an  impact  of  achieving  the  objectives  at  01  and  02. 
Each  impact  is  how  the  different  metrics  are  related  to  one  another.  The  impact 
relationships  are  relating  to  the  contribution  of  lower-level  metrics  to  higher-level  metrics 
that  when  summed  equal  unity.  It  is  a  SME  defined  relationship  between  the  different 
levels  (Turner  2014).  Although  the  mathematical  graph  provides  a  visual  of  the 
relationships  present  in  the  system,  it  does  not  represent  a  functional  hierarchy  as 
discussed,  or  the  decisions,  processes  and  activities  of  an  organization  like  an  IDEFO 
model  (Parnell  Driscoll,  and  Henderson  2011).  An  IDEFO  model  is  a  much  more  robust 
method  of  visually  representing  a  decomposed  system. 
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I. 


GAPS  IN  CURRENT  RESEARCH 


Turner’s  (2014)  work  on  modeling  of  NOSs  for  simulations  is  significant  because 
it  is  unique.  All  other  references  to  a  NOS  in  the  body  of  literature  have  been  to  define 
the  term  and  the  concepts,  not  how  to  build  the  models  or  validate  them  for  system  use  in 
the  real  world.  Turner  (2014)  identifies  a  need  for  an  approach  to  decompose  a  system. 
Based  on  the  limited  information  within  the  body  of  knowledge  of  modeling  NOSs, 
Turner  assumes  that  decomposing  a  system  helps  to  identify  the  relationships  between  the 
metrics  that  have  the  most  impact  on  the  system.  He  uses  a  mathematical  graph  to  display 
the  relationship  between  metrics. 

Finally,  Turner  (2014)  identifies  two  areas  of  continued  work  in  the  field  of 
modeling  of  NOSs  for  simulation  at  the  end  of  his  research.  It  is  in  these  areas  where 
further  contribution  to  the  body  of  knowledge  is  made  and  provides  the  following: 

•  Better  transition  from  system  definition  to  impact  variable  decomposition 

•  Proper  development  of  structure  for  decomposition 

Again,  SE  methods  will  be  used  in  this  research  to  continue  the  previous  work  to 
improve  the  method  of  validation  of  models  of  NOSs  so  it  is  traceable  and  support 
current  SME  validation  methods. 

J.  VALUE  MODEL 

Value  modeling  provides  a  quantitative  model  that  provides  stakeholders  feedback 
on  what  they  value  as  the  most  important  functions  of  the  system.  The  value  modeling 
process  provides  an  opportunity  for  stakeholders  to  become  more  involved  in  the  model 
development.  For  this  research,  the  value  model  is  used  to  assess  the  impact  of  the 
functions  on  the  entire  system  given  the  weight  placed  on  the  function  by  the  stakeholders. 

The  value  model  built  for  this  research  uses  the  functional  analysis  to  determine 
functions,  objectives,  and  measures.  Parnell,  Driscoll,  and  Henderson  (201 1)  define  steps 
to  creating  a  value  model  as  quoted  here: 

•  Identify  the  fundamental  objective 

•  Identify  functions  that  provide  value 
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•  Identify  objectives  that  define  value 

•  Identify  value  measures 

•  Discuss  the  value  model  with  key  stakeholders  (327). 

The  value  hierarchy  is  created  using  the  steps  identified  above.  Figure  20  shows 
the  structure  of  a  value  hierarchy.  The  fundamental  objective  is  at  the  top.  The  next  level 
shows  the  functions  required  to  be  performed  to  meet  the  functional  objective.  The 
objectives  below  the  functions  provide  a  preference  of  whether  the  stakeholders  want  to 
maximize  or  minimize  the  objectives  that  define  the  value.  The  lowest  level  is  the  value 
measures  that  are  aligned  with  the  objectives.  The  values  measures  can  be  collected  either 
directly  or  by  proxy  (Kirkwood  1997).  Proxy  measures  would  be  taken  for  the  effects  of 
the  interaction  between  the  system  and  the  external  system  because  it  is  non-observable. 


Figure  20.  Structure  of  a  Value  Hierarchy 


Source:  Parnell,  Gregory  S.,  and  Driscoll,  Patrick  J.,  and  Henderson,  Dale  L.  2011, 
Decision  Making  in  Systems  Engineering  and  Management.  New  Jersey,  John  Wiley  & 
Sons,  329. 
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K.  SUMMARY 


The  M&S  community  continues  to  find  ways  to  meet  the  challenges  of  modeling 
complex  systems  that  are  difficult  to  predict.  Several  MDPs  are  presented  in  the 
literature;  however,  the  commonality  among  all  of  the  MDPs  is  the  need  for  a  conceptual 
model  validation.  The  need  for  a  well-structured  and  validated  CoM  takes  even  more 
prominence  during  the  operational  validation  of  NOSs.  The  concept  of  a  NOS  is  not  well 
defined  within  the  M&S  domain.  Other  fields,  such  as  control  theory  and  fault  tolerance 
domains,  have  used  the  term  in  similar  ways.  Control  theory  uses  observability  to  address 
the  internal  state  of  the  system  inferred  by  its  outputs  (Kalman  1959).  Fault  tolerance 
uses  it  to  describe  a  failed  system  where  the  system  is  unobservable  because  it  does  not 
keep  a  record  of  its  requirements  (Buede  2009).  Sargent  (2010)  applies  the  term  NOS  “as 
not  possible  to  collect  data  on  the  operational  behavior  of  the  problem  entity  (system), 
thus  there  is  not  a  high  degree  of  trust  in  the  model.”  Other  examples  in  literature  refer  to 
future  systems  with  little  or  no  knowledge  to  be  designed,  modeled  and  validated  as 
NOSs. 

Current  methods  of  validation  of  NOSs  have  primarily  been  through  subjective 
validation  techniques,  such  as  face  validation  (Turner  2014).  There  is  a  need  to  find 
another  method  of  validating  models  of  systems  by  ensuring  it  is  traceable  and 
defensible.  Recent  attempts  at  modeling  NOSs  for  simulation  have  reinforced  the 
importance  of  a  well-structured  CoM.  This  research  is  the  first  known  attempt  to  ensure 
that  multiple  validation  methods  are  used  for  building  COMs  of  systems  to  support 
operational  validation  ensuring  traceability  and  defensibility.  The  use  of  SE  processes 
improves  the  modeling  of  these  systems  for  validation.  The  SE  process  uses  functional 
and  physical  decomposition  methods  to  identify  relationship  and  use  allocated 
architecture  to  ensure  system  functions  are  performed  by  the  correct  component.  While 
the  mathematical  graph  is  a  simple  way  to  identify  how  lower  level  of  metrics  affects  the 
higher,  SE  models,  such  as  the  IDEF0  model,  shows  the  complexity  of  a  system  in 
greater  detail.  Finally,  a  more  analytical  method  of  assigning  impacts  of  the  different 
functions  and  components  is  the  use  of  the  multi-objective  decision  analysis  (MOD A) 
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techniques.  SMEs  are  still  heavily  involved  in  a  MODA  and  have  a  method  of  tracing 
their  values  to  the  model. 

Finally,  Buede’s  (2009)  description  of  the  interactions  of  the  system  to  external 
systems  provides  a  visual  of  the  system  and  how  it  impacts  the  external  system.  This 
interaction  occurs  during  the  execution  of  the  simulation  during  the  MDP.  The  validation 
of  the  CoM  improves  the  expectation  of  the  system  prior  to  the  execution  of  the 
simulation.  The  improved  understanding  ensures  analysts  and  DMs  are  able  to  interpret 
the  results  of  the  simulation  even  with  limited  or  no  observation  of  system’s  behavior 
during  the  simulation.  Using  Sargent’s  (2001)  MDP  and  SE  concepts  as  a  foundation  of 
understanding  improves  the  conceptual  model  traceability  to  the  components,  and 
facilitates  greater  SME  involvement  with  conceptual  model  development.  The  end 
product  is  a  validated  model  of  a  system,  in  which  DMs  can  rely  on  to  make  critical 
decisions. 
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III.  IMPROVED  CONCEPTUAL  MODEL  METHODOLOGY 


The  ICoMM  introduced  in  this  dissertation  focuses  on  improving  the  structure  of 
the  CoM  during  the  MDP.  The  improved  structure  better  facilitates  the  use  of  face  and 
traces  validation  techniques  for  CoM  validation  and  supports  operational  validation  of 
NOSs.  The  basis  of  this  method  is  the  continuation  of  previous  research  on  development 
of  models  for  simulations  of  NOSs  by  Turner  (2014).  In  2014,  Turner  states  that  his 
research  lacks  a  clear  methodology  to  improve  transition  from  system  definition  to 
impact  variable  decomposition.  Turner  (2014)  defines  impact  variables  as  “the 
relationship  of  lower  level  metrics  contributing  to  higher-level  metric”  (111).  He  also 
identifies  the  need  to  conduct  further  research  into  proper  development  of  its  [model] 
structure  (Turner  2014). 

ICoMM  improves  the  structure  of  the  conceptual  model  by  SE  and  SA  to 
Sargent’s  evolved  MDP.  A  model  is  a  representation  of  a  system.  ICoMM  presents  the 
idea  that  SE  processes  should  be  used  to  build  the  model  of  a  system.  SE  “focuses  on 
identifying  customer  needs  and  functionality  early  in  the  development  process, 
documenting  requirements,  then  proceeding  with  design  synthesis  and  system  validation 
while  considering  the  complete  problem”  (INCOSE  2015).  A  CoM  describes  system 
functions  and  the  execution  of  the  functions  to  achieve  the  fundamental  objective  (Law 
2007).  SE  and  SA  methods  support  the  ICoMM  by  identifying  the  components  of  their 
interfaces  and  concept  of  execution. 

The  value  of  ICoMM  is  an  improved  structure  of  the  CoM  that  facilitates  the 
identification  of  a  single  fundamental  objective,  early  inclusion  of  SMEs,  and 
identification  of  external  system  functions  that  affects  the  fundamental  objective. 
Identification  of  a  single  fundamental  objective  focuses  the  system  and  its  components  to 
one  overarching  objective.  ICoMM  reduces  the  confusion  of  performance  measurements 
leading  to  multiple  objectives  by  facilitating  traces  of  measurements  and  sub-objectives 
leads  to  the  fundamental  objective.  All  the  components  are  aware  of  its  contribution 
towards  fundamental  objective.  SMEs  are  required  for  the  development  of  the  CoM  early 

in  the  MDP.  SMEs  weights  of  functions  are  documented  and  then  evaluated  at  the  end  of 
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the  simulation.  The  CoM  must  be  reevaluated  if  there  is  a  deviation  from  the  actual 
output  from  the  output  envisioned  by  the  DM.  The  first  item  to  be  investigated  is  the 
weights  of  the  functions  provided  by  the  SMEs.  The  SMEs  are  held  accountable  by  the 
weights  of  the  functions  assigned  by  the  SMEs.  The  identification  of  the  external  system 
shows  the  potential  of  how  the  external  system  interacts  with  the  system  to  either  enhance 
or  degrade  the  achievement  of  the  fundamental  objective.  The  interaction  between  the 
two  systems  may  be  non-observable;  a  well-structured  CoM  helps  to  identify  points  of 
interaction. 

A.  CONCEPTUAL  MODEL  DEVELOPMENT  PROCESS  DEFINITION 

This  chapter  revisits  Sargent’s  (2001)  evolved  MPD  to  focus  on  the  CoM  phase 
and  CoM  validation  of  the  simulation  world.  ICoMM  presents  a  generic  SE  process 
model  to  include  system  architecting  in  the  development  of  the  CoM.  A  value  model  is 
also  included  to  identify  SME  inputs  into  the  development  of  the  CoM.  SME 
involvement  in  the  development  of  the  CoM  is  critical  early  in  the  MDP,  rather  than 
providing  expertise  at  the  conclusion  of  a  simulation.  The  following  steps  are  used  in 
ICoMM  to  develop  the  structure  of  the  CoM: 

1 .  Understanding  the  Operational  Concept 

a.  Stakeholder  Analysis 

b.  Requirements  Analysis 

2.  Develop  System  Architecture 

a.  Functional  Architecture  Development 

b.  Physical  Architecture  Development 

c.  Allocated  Architecture  Development 

3.  Gather  SMEs  Values 

a.  SME  Weight  of  Functions 

b.  Impact  of  the  Functions 

4.  Model  Exploration  of  Non-Observable  Systems 

Following  Sargent’s  (2001)  evolved  MDP,  we  concentrate  on  the  process  between 
systems  theories  and  conceptual  model  phases.  His  evolved  MDP  simply  has  the  term 

modeling  between  system  theories  and  conceptual  model.  ICoMM  updates  the  model  to 
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include  Buede’s  (2009)  “Architecture  development  in  the  engineering  of  a  system”  model 
by  replacing  the  simple  “modeling.”  ICoMM  provides  a  fills  the  gap  that  Turner  in  his 
research  states  is  needed  to  investigate  a  better  transition  from  system  definition  to 
impact  variables.  Figure  21  shows  the  “inclusion  of  architecture  development  in  the 
engineering  of  a  system”  (Buede  2009)  as  a  part  of  Sargent’s  evolved  MDP.  It  also 
identifies  the  two  validation  techniques,  face  and  traces,  that  are  used  to  validate  CoMs. 


Figure  21.  Introduction  of  Systems  Engineering  and  Systems  Architecture  in 

the  Model  Development  Process 


Adopted  from:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying 
and  Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation 
Conference,  109. 


B.  IMPROVEMENT  OF  THE  CONCEPTUAL  MODEL 

An  initial  understanding  of  the  system  is  needed  to  transition  the  system  from  the 

real  world  to  the  simulation  world.  The  real  world  identifies  the  need  for  a  system  to 
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address  a  deficiency  (Blanchard  and  Fabrycky  2006).  ICoMM  assumes  that  the  need  has 
been  identified  and  requires  a  system  to  be  built  to  address  the  deficiency.  ICoMM 
facilitates  the  identified  needs  of  the  system  from  the  real  world  to  enter  the  simulation 
world  to  build  models  of  the  system  to  help  DMs  gain  insights  and  make  decisions. 

1.  Operational  Concept 

The  process  begins  by  establishing  an  operational  concept.  A  system  is  created  to 
execute  functions  to  achieve  an  objective  in  the  real  world.  The  operational  concept 
provides  a  general  picture  of  the  functions,  components,  and  the  objectives  of  the  system. 
It  provides  a  description  of  the  functions  and  the  products  produced  by  the  system.  It 
facilitates  understanding  of  the  system  and  the  context  and  its  execution  as  directed  by 
the  DM.  The  operational  concept  includes  scenarios  that  describe  how  the  system 
interacts  with  external  systems  (Buede  2009).  It  is  a  shared  idea  of  the  system  among  all 
of  the  stakeholders  (Buede  2009).  The  only  outcome  of  this  phase  is  a  shared 
understanding  of  the  system. 

The  established  operational  concept  of  the  system  is  used  by  ICoMM  to  begin 
developing  the  CoM.  The  operational  concept  establishes  the  functions  and  the 
components  of  the  system,  as  well  as  descriptions  of  the  external  system  and  the  context 
in  which  the  system  operates.  Figure  22  shows  the  system  and  its  interactions  with  the 
external  system.  The  interactions  with  the  external  system  can  be  in  one  direction  or  both 
directions.  The  entity  that  provides  the  context  for  the  system  is  only  in  one  direction. 
The  context  scopes  and  bounds  the  system’s  activities  during  the  execution  of  the  system 
functions.  The  system  cannot  affect  the  entity  providing  the  context.  The  operational 
concept  defined  in  this  phase  is  the  basis  for  which  to  establish  the  structure  of  the  CoM. 
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Figure  22.  Depiction  of  the  System,  External  System,  and  Context 


System 


Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons,  50. 


a.  Stakeholder  Analysis 

Stakeholder  analysis  is  the  initial  step  in  developing  the  operational  concept.  This 
step  identifies  the  objectives,  the  functions,  components,  constraints,  and  values  of  the 
DM  (Parnell,  Driscoll  and  Henderson  2011).  Stakeholder  analysis  can  be  conducted  in 
many  ways,  such  as  interviews,  surveys,  and  focus  groups.  This  dissertation  uses  the 
operational  concept  established  by  SE  analysis  cohort  17,  Team  A  for  their  master’s 
thesis. 


b.  Requirements  Analysis 

Another  aspect  of  the  operational  concept  is  the  requirements  analysis. 
Requirements  analysis  addresses  the  need  and  objectives  of  the  system  (Buede,  2009). 
The  top  requirement  is  the  overall  requirement  of  the  system.  All  the  stakeholders  support 
this  requirement.  This  requirement  requires  the  interaction  of  several  subcomponent 
systems,  as  well  as  external  systems. 
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An  introduction  in  this  dissertation  is  that  ICoMM  also  adds  the  requirements  of 
the  external  system  as  part  of  the  requirements  analysis.  External  systems  also  have 
requirements  that  must  be  met  to  support  the  top  requirement.  Figure  23  shows  a 
depiction  of  requirements  analysis.  The  external  system  is  identified  in  a  gray  box,  but 
shows  a  linkage  between  the  top  requirements  and  the  external  system  requirement.  This 
is  an  extension  of  Figure  21,  Buede’s  (2009)  “depiction  of  system,  external  system,  and 
context”  designing  the  system  to  include  the  external  system. 


Figure  23.  An  Example  of  a  Requirements  Analysis  with  External  System 
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2.  System  Design 

Designing  of  the  system  begins  once  the  operational  concept  has  been  defined 
(Buede,  2009).  Systems  design  is  the  transformation  of  a  system  in  the  stakeholders’ 
minds  into  models  into  visual  formats  (Buede,  2009).  ICoMM  supports  the  establishment 
of  the  concepts  within  the  minds  of  the  DMs  into  visible  CoMs  for  simulations.  Systems 
design  takes  the  operational  concept  presented  earlier  and  conducts  decomposition  of  the 
functional  and  physical  representations  of  the  system  (Buede,  2009).  The  functional 
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architecture  identifies  the  functions  that  must  be  executed  to  meet  the  requirements.  The 
physical  architecture  identifies  the  physical  components  that  are  part  of  the  system.  The 
allocated  architecture  identifies  the  allocation  of  which  physical  components  will  execute 
the  functions  to  meet  the  identified  requirements  (Buede,  2009). 

Figure  24  shows  how  once  the  operational  concept  of  the  system  is  developed,  the 
decomposition  and  the  integration  begin.  The  functional  and  physical  decomposition  of 
the  system  is  performed  by  the  architecture.  Buede  (2009)  describes  “the  functional  and 
physical  architectures  are  developed  in  parallel  to  provide  more  meaning  when  integrated 
to  form  an  allocated  architecture”  (27). 


Figure  24.  Architecture  Development  in  the  Engineering  of  a  System 


Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons,  28. 


ICoMM  integrate  the  systems  architecting  process  into  the  MDP  to  improve  the 
structure  of  the  CoM,  as  seen  in  Figure  1.  Incorporating  systems  architecture  into  the 
MDP  to  develop  the  CoM  ensures  that  the  models  will  more  accurately  represent  the 
system.  In  addition,  establishing  a  structured  methodology  to  build  the  CoM  increases  the 
traceability  of  the  model  as  ICoMM  demonstrates  in  Chapter  IV. 
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a.  Functional  Architecture 

ICoMM  uses  functional  architecture  to  define  what  the  system  must  do.  The 
functional  architecture  is  a  decomposition  of  the  system’s  top-level  functions  (Buede 
2009).  It  identifies  the  functions  that  the  system  is  required  to  execute.  A  functional 
hierarchy  is  created  to  show  the  lower-level  functions  and  the  link  to  the  top-level 
function  it  supports  as  shown  in  Figure  25.  Once  again,  ICoMM  integrates  the  functions 
of  the  external  system  to  show  its  relationship  to  the  system.  The  functions  of  the  external 
system  influence  the  execution  of  the  top-level  function. 


Figure  25.  An  Example  of  the  Functional  Hierarchy 
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Next,  ICoMM  identifies  the  sequence  of  the  function  by  using  the  EFFBD  as  seen 
in  Figure  26.  The  EFFBD  displays  the  functions  and  the  sequence  it  is  performed.  The 
EFFBD  provides  dynamic  information,  which  the  IDEFO  model  cannot  display.  Figure 
25  shows  that  the  two  functions,  perform  air  connector  and  perform  surface  connector, 
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can  be  executed  simultaneously,  while  the  perform  forward  logistics  function  occurs 
afterwards  because  the  forward  logistics  actions  of  distributing  aid  cannot  be  conducted 
until  the  aid  arrives  to  the  forward  logistics  sites.  The  EFFBD  is  the  method  ICoMM  uses 
to  display  this  information. 


Figure  26.  An  Example  of  an  EFFBD 
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b.  Physical  Architecture 

The  components  of  the  system  are  identified  following  the  identification  of  the 
functions.  The  components  are  the  physical  aspects  of  the  system  that  will  execute  the 
functions.  Figure  27  shows  an  example  of  a  physical  architecture  that  identifies  the 
components  of  the  system.  ICoMM  uses  a  generic  physical  architecture  that  defines  the 
physical  hierarchy  in  general  terms  to  understand  what  components  are  included  in  the 
system. 
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Figure  27.  An  Example  of  a  Physical  Architecture 


c.  Allocated  Architecture 

The  allocated  architecture  is  built  after  the  identification  of  the  functions  and  the 
components  that  will  execute  the  functions.  As  seen  in  Figure  28,  ICoMM  maintains  the 
concept  described  in  Buede’s  (2009)  description  of  system,  external  system,  and  context. 
Functions  and  the  components  are  allocated  within  the  system  to  interact  with  the 
external  system.  ICoMM  uses  the  information  about  the  external  system  to  improve  the 
allocation  of  the  functions  to  the  components.  For  example,  a  function  of  delivering  aid 
would  not  be  necessary  for  interacting  with  the  insurgency,  but  provide  the  necessary 
security. 
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Figure  28.  The  Allocated  Architecture  within  Designing  of  a  System 


Adapted  from:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ: 
John  Wiley  &  Sons,  50. 


ICoMM  uses  the  IDEFO  to  display  the  allocated  architecture  visually.  The  IDEFO 
shows  the  system  design  to  include  the  functions  as  inputs  and  outputs,  the  physical 
components  as  the  mechanism  to  perform  the  functions,  and  the  context  of  the  system  as 
the  controls.  Figure  29  is  an  example  of  the  IDEFO  model  displaying  the  input  and 
output,  the  mechanisms,  and  controls.  The  allocated  architecture  provides  the  structure 
that  allows  the  traceability  from  components  to  functions,  and  ultimately,  to  the 
fundamental  objective.  The  traceability  provided  ICoMM  improves  the  facilitation  of 
traces  validation  method  of  conceptual  models. 
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Figure  29.  An  Example  of  an  IDEFO  Model 


3.  Subject  Matter  Expert  Values 

Finally,  ICoMM  includes  a  value  to  model  to  document  SMEs’  values  of 
functions  that  will  be  executed  by  the  system.  Traditionally,  involvement  of  SMEs  for 
model  validation  was  at  the  end  of  the  operational  validation.  ICoMM  ensures  that  the 
SMEs  provide  weights  for  the  functions  by  their  values  of  importance.  These  weights  are 
also  identified  as  the  impact  that  the  function  will  have  on  the  output  of  the  system.  It  is 
the  weights  identified  by  the  SMEs  that  will  be  evaluated  post  simulation  to  conduct 
operational  validation  of  the  NOS.  Figure  30  shows  an  example  of  how  value  curves  are 
included  in  Buede’s  example  of  the  elevator  study.  Buede  (2009)  uses  stakeholders  to 
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solicit  their  values.  Although  the  inputs  of  the  stakeholder  values  are  important,  it  is  the 
solicitation  of  SMEs’  values  of  functions  of  the  system  that  is  the  basis  of  ICoMM. 
ICoMM  facilitates  face  validation  of  the  conceptual  model  where  SMEs  are  required  for 
validation. 


Figure  30.  Objective  Hierarchy  with  Value  Curves 


Source:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ:  John 
Wiley  &  Sons.  186. 


C.  SUPPORTING  OPERATIONAL  VALIDATION  OF  NON-OBSERVABLE 
SYSTEMS 

The  idea  of  a  CoM  is  not  new.  What  is  novel  of  ICoMM  is  the  integration  of  SE 
methods  into  the  MDP  to  build  CoMs  and  to  improve  both  conceptual  and  operational 
validations.  As  seen  in  Figure  31,  ICoMM  addresses  the  operational  validation  needs  of 
systems  that  meet  the  criteria  to  be  classified  as  a  NOS. 
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Figure  3 1 .  Execution  of  Simulation  of  a  NOS 
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Adopted  from:  Sargent,  Robert.  2001.  “Some  Approaches  and  Paradigms  for  Verifying 
and  Validating  Simulations  Models.”  Proceedings  of  the  2001  Winter  Simulation 
Conference ,  109. 


Figure  32  shows  the  flow  of  an  MDP  for  a  NOS.  The  only  information  about  the 
model  of  the  system  is  the  inputs  and  outputs  produced  by  the  simulation.  The  inputs  are 
allocated  functions  and  components  of  the  CoM.  The  outputs  are  the  results  of  the 
simulation.  The  outputs  may  match  or  deviate  from  the  intended  output.  If  the  output 
matches  the  intended  output,  then  it  is  classified  as  an  observable  system  and  the  original 
conceptual  model  is  operationally  validated.  The  model  can  be  presented  to  the  DM  to  be 
used  for  future  scenarios.  If  the  output  is  a  deviation  of  the  intended  output,  then 
operational  validation  of  the  model  is  infeasible  and  it  is  classified  as  a  NOS.  The  only 
method  to  provide  an  operational  validation  of  a  NOS  is  through  model  exploration. 
Thus,  the  CoM  must  be  reexamined.  This  methodology  is  repeated  until  the  output 
matches  the  CoM  through  model  exploration.  The  model  of  the  system  is  determined  to 
be  a  failure  if  the  output  does  not  converge  to  a  correct  model  after  multiple  iterations.  A 
new  system  should  be  designed  to  address  the  deficiency.  If  applied  as  described  in  this 
methodology,  ICoMM  provides  an  effective  means  to  conceptually  and  operationally 
validate  future  CoMs  throughout  the  MDP. 
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Figure  32.  Reference  Back  to  the  Conceptual  Model 


65 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


66 


IV.  APPLICATION  OF  THE  IMPROVED  CONCEPTUAL  MODEL 

METHODOLOGY 


To  demonstrate  the  applicability  of  ICoMM,  an  analysis  of  developing  a  validated 
CoM  of  a  future  DOD  HA/DR  mission  is  presented.  As  mentioned,  this  dissertation 
leverages  Sargent’s  (2001)  evolved  MDP  and  the  inclusion  of  SE  methods  into  the  MDP 
process  to  develop  ICoMM.  It  is  a  continuation  of  the  work  of  Andrew  Turner’s 
“Methodology  for  the  Development  of  Models  for  Simulation  of  Non-observable 
Systems.”  Turner  (2014)  states  the  need  for  an  improved  method  for  system  definition 
and  further  research  into  the  proper  development  of  its  structure  that  lacks  in  his  research 
(330).  Systems  definition  is  “the  identification  of  the  system  of  interest  and  decomposing 
the  system  so  it  can  be  translated  into  model  formation”  (54).  The  HA/DR  mission  was 
chosen  based  on  two  criteria.  First,  the  scenario  is  based  on  missions  DOD  will  execute 
in  the  future.  HA/DR  missions  are  dynamic  and  each  mission  is  different.  Although 
similar  HA/DR  missions  may  have  been  executed,  future  interactions  between  external 
systems  and  the  context  in  which  the  system  operates  in  will  differ.  Second,  the  scenario 
facilitates  the  comparison  of  ICoMM  to  previous  research  conducted  by  Andrew  Turner. 
This  dissertation  presents  ICoMM  as  a  way  to  improve  both  systems’  definition  and 
structure  of  the  model  to  demonstrate  its  contribution.  ICoMM  furthers  the  research  by 
strengthening  the  validation  of  the  CoM  and  its  support  to  operational  validation  of  a 
NOS.  This  dissertation  is  not  intended  to  be  a  criticism  of  the  previous  research,  but 
rather  the  acknowledgement  of  the  novel  concept  of  modeling  a  NOS  and  addressing  a 
necessary  expansion  to  validate  models  of  a  NOS.  It  is  the  intent  of  this  dissertation  to 
use  ICoMM  to  develop  models  of  systems  that  are  trusted  by  DMs  to  make  critical 
decisions. 

This  chapter  applies  ICoMM  to  a  scenario  that  requires  a  CoM  to  be  developed 
and  validated  and  to  be  executed  in  a  simulation.  The  CoM  is  developed  with  SME  input 
and  improved  structure  to  be  traceable  for  model  exploration  after  the  execution  of  a 
simulation.  The  identification  of  system  need  is  already  established  in  the  scenario. 
ICoMM  is  applied  from  the  operational  concept  to  conduct  system  definition  and 
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decompose  the  system  to  build  the  functional,  physical,  and  allocated  architectures. 
Finally,  ICoMM  define  the  impact  of  each  of  the  functions  of  the  system  with  the  value 
model. 

A.  HUMANITARIAN  ASSISTANCE  /  DISASTER  RELIEF  SCENARIO 

SELECTION 

This  dissertation  investigates  a  HA/DR  scenario  to  compare  previous  research  of 
modeling  of  NOSs  by  Turner.  The  scenario  is  based  on  a  master’s  thesis  by  the  Naval 
Postgraduate  School,  Systems  Engineering  Cohort  17  in  2011  about  the  influence  of 
foreign  HA/DR  in  a  coastal  nation  (Alexander  et  al.  2011).  Again,  this  scenario  was 
chosen  because  this  research  is  a  continuation  of  Turner’s  research. 

The  HA/DR  scenario  meets  the  definition  of  NOSs  defined  earlier  as  non-ability 
to  observe  the  behavior  of  the  interaction  of  two  systems  and  the  result  is  the  deviation  of 
actual  effects  from  the  intended  effects.  The  data  of  the  interaction  between  the  system 
and  the  external  systems  cannot  be  directly  collected  during  the  execution  of  this 
scenario.  The  operational  validation  of  this  model  is  infeasible  for  this  scenario  due  to  its 
classification  as  a  model  of  a  NOS.  Thus,  the  operational  validation  is  conducted  by 
model  exploration  of  the  CoM  and  face  validation  methods  relying  on  SMEs. 

The  scenario  is  set  in  the  future  in  a  conceptual  environment  with  very  little 
information  of  the  population  and  their  social  issues.  The  military  system  conducting  the 
HA/DR  effort  includes  components,  such  as  the  T-Craft,  a  high-speed/high-volume  cargo 
carrier  not  part  of  the  current  U.S.  Naval  fleet.  The  success  of  the  operation  depends  on 
the  satisfaction  of  the  population  receiving  the  aid  and  the  reduction  of  the  population 
into  criminal  behavior  (Alexander  et  al.  2011).  These  two  success  criteria  are  based  on 
the  interaction  between  the  military  system  and  the  local  populous. 

HA/DR  is  one  of  the  very  important  missions  that  the  U.S.  military  has  been 
participating  in  for  many  years.  In  2013,  the  United  Nations  reported  880-loss  events 
worldwide  (Munich  RE  2014).  A  graphic  depiction  is  seen  in  Figure  33.  The  United 
States  has  been  the  largest  provider  of  humanitarian  assistance  by  contributing  $4.7 
billion  worldwide.  The  largest  recipients  of  U.S.  assistance  have  been  sub-Saharan 
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countries  in  Africa.  For  the  past  decade,  sub-Saharan  countries  received  59%  of  overall 
U.S.  aid  (Global  Humanitarian  Assistance  2013). 


Figure  33.  Loss  Worldwide  Event  2013 
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Alexander  et  al.  (2001)  also  states  that  the  group’s  reason  for  selection  of  this 
scenario  is  that  OPNAV  N8F  directed  a  study  into  the  designing  of  systems  architecture 
to  support  a  HA/DR  mission  for  a  developing  nation.  The  design  team  was  requested  to 
design  and  assess  a  system  that  provides  continual,  multi-year  support  for  a  host  nation’s 
efforts  to  ensure  security  and  stability  during  a  HA/DA  mission.  The  primary  goal  was  to 
develop  a  “regional  stability  systems  architecture.”  This  system  would  consist  of  a  sea 
base  and  sea  base  connectors  with  the  following  capabilities: 

•  Disrupt  social  interruption  activities  and  provide  humanitarian  aid  through 
the  use  of  joint  and  coalition  naval  forces 

•  Address  potential  local  population  support  for  disruptive  forces 
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•  Address  the  reasons  for  enemy  forces  to  engage  in  disruptive  activities 
(Office  of  the  Chief  of  Naval  Research  2011) 

The  concept  of  the  HA/DR  mission  is  based  on  Expeditionary  Warrior  10  (EW10) 
wargame  scenario  developed  at  the  USMC  Wargaming  Division.  The  overarching 
questions  to  answer  are,  “how  well  is  aid  being  distributed  to  the  population  and  the 
effect  of  HA/DR  on  the  population”  (United  States  Marine  Corps  Wargaming  Division, 
Marine  Corps  Warfighting  Laboratory  2010).  ICoMM  builds  a  conceptual  model  to 
address  the  questions  posed  by  OPNAV  N8F  and  the  USMC  Wargaming  Division  by 
identifying  the  functions  of  the  system,  the  external  system,  and  their  interactions. 

B.  SCENARIO  OVERVIEW 

The  HA/DR  scenario  presented  by  Alexander  et  al.  (2011)  is  set  in  2022.  A 
devastating  storm  greatly  damaged  the  western  African  region  with  great  destruction  and 
heavy  flooding.  The  Country  of  Orange  (COO),  at  the  limits  of  its  internal  emergency 
resources,  requested  foreign  assistance  to  the  United  Nations  (UN).  The  United  States, 
which  is  a  member  nation  of  the  UN,  responded  to  the  request  for  assistance.  The  DOD 
was  tasked  to  provide  immediate  support  to  the  disaster  region  by  sending  a  Naval 
expeditionary  strike  group  (ESG)  composed  of  a  Marine  expeditionary  unit  (MEU) 
capable  of  conducting  HA/DR  missions.  ICoMM  is  applied  to  this  scenario  to  improve 
the  structure  of  the  CoM  by  including  the  external  system  and  context  to  the 
architectures. 

C.  OPERATIONAL  CONCEPT  DEVELOPMENT 

A  review  of  the  operational  concept  for  the  HA/DR  scenario  is  conducted  to 
identify  the  system,  external  system,  and  potential  interactions.  The  operational  concept 
defines  how  the  military  systems  will  be  used  to  interact  with  local  systems  during  the 
HA/DR  operation. 

The  U.S.  military,  with  support  from  other-government  organizations  (OGOs), 
such  as  the  State  Department’s  United  States  Agency  for  International  Assistance 
(USAID)  and  non-government  organizations  (NGOs),  are  called  to  provide  aid  to  the 

people  of  Orange.  The  main  effort  of  the  HA/DR  mission  will  be  from  the  sea  due  to 
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heavy  damages  to  Orange’s  infrastructure.  An  off  shore  sea  base  will  start  the  two  stage 
relief  effort.  In  the  initial  stage,  aid  will  be  transported  from  a  sea  base  to  a  forward 
logistics  site  (FLS)  and  to  the  forward  logistics  satellite  site  (FLSS).  The  second  stage  is 
to  deliver  the  aid  from  the  FLSS  to  the  local  populous.  Figure  34  shows  the  flow  of  the 
operation  and  an  overview  of  the  mission. 


Figure  34.  Operational  Overview  of  the  HA/DR  Mission 


Source:  Alexander  et  al.  2011.  “Influence  of  Foreign  Humanitarian  Assistance/Disaster 
Relief  in  a  Coastal  Nation.”  Master’s  thesis,  Naval  Postgraduate  School,  7. 


Four  courses  of  action  (COAs)  were  presented  for  the  delivery  of  aid.  The  courses 
of  actions  differ  on  the  matter  of  who  will  directly  deliver  the  aid  to  the  local  populous.  In 
the  first  COA,  the  military  delivered  aid  material  to  the  FLS  only  and  the  non-military 
organizations  would  provide  delivery  to  the  FLSS,  and  subsequently,  to  the  populous.  For 
COA  2,  the  military  would  deliver  to  all  the  FLSs  and  the  FLSSs.  This  COA  would  use 
more  military  resources;  however,  but  would  ensure  that  security  was  provided  to  the 
people.  For  COAs  3  and  4,  the  delivery  of  aid  would  be  conducted  in  stages  to  the  FLS 
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first  and  then  to  the  FLSS.  The  difference  between  COAs  3  and  4  is  that  local  security 
would  not  be  present  at  the  FLSS  in  COA  3.  Figure  35  displays  the  different  COAs. 


Figure  35.  Four  Courses  of  Action  Overview 
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Source:  Alexander  et  al.  2011.  “Influence  of  Foreign  Humanitarian  Assistance/Disaster 
Relief  in  a  Coastal  Nation.”  Master’s  thesis,  Naval  Postgraduate  School,  xxxvi. 


1.  Course  of  Action  Decision 

COA  2  is  selected  for  the  proof  of  concept  following  the  work  of  Turner’s  (2014) 
research  to  demonstrate  the  modeling  NOSs  for  simulations.  Modeling  of  the  other  COAs 
requires  a  model  for  each  of  the  COAs,  which  is  redundant  and  time  consuming.  Another 
reason  for  COA  2  selection  is  that  the  SE  Cohort  17  in  their  capstone  project 
demonstrated  that  COA  2  was  the  optimal  COA  for  their  research.  COA  2  is  used  to  build 
the  system  architecture  to  demonstrate  its  traceability.  COA  2  is  also  simplest  in  concept. 
All  the  platforms  directly  deliver  aid  to  the  FLS  and  the  FLSS  with  security.  The  air 
connectors  deliver  aid  to  the  FLSS  located  in  remote  locations  away  from  access  to  the 
sea.  The  surface  connectors  deliver  to  the  FLS,  which  are  closer  to  access  from  the  sea. 
Figure  36  shows  the  path  the  surface  connectors  use  and  Figure  37  shows  the  air 
connector  path  to  deliver  aid. 


72 


Figure  36.  Surface  Connector  Path  to  the  FLS 


Source:  Alexander  et  al.  2011.  “Influence  of  Foreign  Humanitarian  Assistance/Disaster 
Relief  in  a  Coastal  Nation.”  Master’s  thesis,  Naval  Postgraduate  School,  55. 


Figure  37.  Air  Connector  Path  to  the  FLSS 


Source:  Alexander  et  al.  2011.  “Influence  of  Foreign  Humanitarian  Assistance/Disaster 
Relief  in  a  Coastal  Nation.”  Master’s  thesis,  Naval  Postgraduate  School,  57. 
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The  flight  paths  of  the  air  connectors  vary  based  on  the  number  of  platforms  and 
the  consumption  of  fuel  to  travel  to  the  FLSS.  The  flight  paths  and  the  course  the  sea 
connectors  take  to  the  logistic  sites  were  not  calculated  because  it  is  not  in  the  scope  of 
this  research.  This  research  does  not  address  the  optimal  travel  paths  or  network  analysis. 

2.  Identification  of  Systems 

The  first  step  in  ICoMM  is  to  identify  the  systems  involved  in  the  scenario.  Figure 
38  provides  a  picture  of  the  identified  system,  external  system,  the  context  in  which  they 
operate  and  the  relationships  between  them.  The  two  main  systems  in  this  scenario  are 
the  actual  system  that  we  know  and  the  external  system  that  the  system  will  be  impacting. 
The  U.S.  military  HA/DR  unit  is  the  system  with  available  data  and  the  DM  has  the 
ability  to  change  its  composition  or  COA.  These  decisions  are  based  on  the  impact  the 
system  has  on  the  external  system.  The  external  system  in  this  scenario  is  the  COO.  The 
HA/DR  mission  unit  conducts  HA/DR  operations  in  the  COO  and  must  determine  if  its 
actions  are  achieving  the  intended  effects  as  envisioned  by  the  DM.  The  double-headed 
arrow  between  the  two  systems  is  used  to  show  that  the  actions  of  both  systems  may 
influence  each  other. 


Figure  38.  Systems  Relationship  Diagram 
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Adapted  from:  Buede,  Dennis.  2009.  The  Engineering  Design  of  Systems.  Hoboken,  NJ: 
John  Wiley  &  Sons,  50. 
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a.  The  Country  of  Orange 

Orange  is  an  African  nation  strategically  situated  next  to  the  Gulf  of  Orange  on 
the  west.  Figure  39  shows  the  three  major  population  centers  of  the  country  of  Orange. 
Two  major  population  centers  are  in  state  number  one  and  one  population  center  in  State 
number  two.  All  three  major  population  centers  can  access  the  Gulf  of  Orange. 


Figure  39.  The  Geography  of  Orange 
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Adapted:  Alexander  et  al.  2011.  “Influence  of  Foreign  Humanitarian  Assistance/Disaster 
Relief  in  a  Coastal  Nation.”  Master’s  thesis,  Naval  Postgraduate  School,  4. 


Orange  politically  has  many  internal  problems.  It  is  a  diverse  country  with  a 
population  of  179  million  divided  into  250  different  ethnic  groups.  The  majority  of  the 
population  is  divided  into  70  million  Muslims  in  the  north  and  70  million  Christians  in 
the  south.  In  the  north,  radical  Islamic  groups,  such  as  Al  Qaeda  in  Islamic  Maghreb 
(AQIM),  is  very  active,  while  a  growing  number  of  participants  in  the  Movement  for  the 
Emancipation  of  Southern  States  insurgency  in  the  south  threaten  the  stability  of  Orange. 
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The  storm  has  had  devastating  impact  on  the  population  of  Orange.  Table  3  shows 
the  breakdown  of  the  population  and  the  effects  of  the  devastating  storm.  The  storm  had 
the  most  effect  on  the  two  western  states  of  1  and  3.  State  #2  in  the  eastern  most  region 
was  least  affected.  However,  State  #2  also  host  hostile  feelings  towards  the  GOO  and 
may  conduct  anti-government  activities  to  influence  the  populous  to  turn  against  the 
Government  of  Orange  (GOO). 


Table  3.  Breakdown  of  the  Population  and  the  Effects  of  the  Storm 


State 

Population 

(mil) 

#  Dead 

#  Injured 

#  Diseased 

#  Displaced 

Total  Affected 

Attitudues 

toward 

mission 

1 

4.1 

85 

750 

2000 

97,000 

243,000 

Neutral 

2 

1.7 

5 

150 

300 

17,000 

25,000 

Hostile 

3 

5.2 

35 

350 

600 

19,600 

34,000 

Neutral 

Total 

11 

125 

1250 

2900 

133,600 

302,000 

b.  The  Humanitarian  Assistance/Disaster  Relief  Mission  Unit 

The  DOD  directed  a  Naval  ESG  to  execute  the  HA/DR  mission  in  support  of  the 
COO.  The  ESG  sent  a  MEU  to  begin  an  initial  push  into  the  COO  with  its  forces  and 
capabilities.  The  MEU  provides  important  capabilities  that  will  be  needed  to  execute  the 
mission.  The  MEU  is  comprised  of  2,200  Marines  and  has  the  capabilities  to  provide  air 
connection  and  surface  connection,  as  well  as  internal  security.  The  sea  base  conducts 
command  and  control  (C&C)  of  the  mission. 

The  sea  base  is  comprised  of  three  amphibious  ships:  A  Wasp  class  Landing 
Helicopter  Deck  (LHD),  a  San  Antonio  class  Landing  Platform  Dock  (LPD),  and  a  Dock 
Landing  Ship  (LSD).  The  LHD,  being  the  largest  of  the  three  ships,  will  provide  the 
overall  C&C.  All  three  ships  carry  vehicles  with  a  capability  to  connect  to  the  FLS  and 
the  FLSS.  The  air  connector  duties  will  be  conducted  by  three  different  aircrafts:  MH  53, 
Sea  Stallion,  MV-22  Osprey,  and  the  SH-60B,  Sea  Hawk.  The  surface  connection  will  be 
performed  by  two  platforms,  the  Landing  Craft  Air  Cushion  (LCAC)  and  the  Landing 
Craft  Utility  (LCU).  Figure  40  shows  the  different  platforms  that  will  be  executing  the 
HA/DR  missions.  The  specifications  of  all  the  platforms  are  listed  in  Appendix  B. 
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Figure  40.  MEU  Vehicles  Participating  in  the  HA/DR  Mission 
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Adapted  from:  Alexander  et  al.  2011.  “Influence  of  Foreign  Humanitarian 
Assistance/Disaster  Relief  in  a  Coastal  Nation.”  Master’s  thesis,  Naval  Postgraduate 
School,  44. 

A  forward  logistical  site  also  supports  the  HA/DR  mission  for  the  DOD.  The  Joint 
Staff  publication  3-35  defines  the  Naval  FLS  as  the  following: 

An  overseas  location,  with  port  and  airfield  facilities  nearby,  which 
provides  logistic  support  to  naval  forces  within  the  theater  of  operations 
during  major  contingency  and  wartime  periods.  (JP  3-35  2013,  GL-7) 

The  HA/DR  mission  to  support  the  COO  establishes  two  types  of  logistics  sites,  a 
FLS  and  a  FLSS  to  support  the  distribution  of  aid  to  the  local  populous.  The  FLS  and  the 
FLSS  work  with  government  and  non-government  agencies  to  deliver  and  distribute  aid 
to  those  who  cannot  travel  to  the  logistic  sites.  The  FLS  is  the  larger  of  the  two  types  and 
is  established  near  three  major  population  centers  of  A,  B  and  C  and  near  watercraft  entry 
points.  There  are  no  FLS  in  State  #3  due  to  the  lack  of  a  major  population  center.  The 
location  of  the  FLSS  is  also  based  on  the  distribution  of  the  population  throughout  the 
country.  There  are  41  FLSSs  to  support  the  HA/DR  mission.  Figure  41  depicts  the 
locations  of  the  FLS  and  the  FLSS. 
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Figure  41.  Locations  of  the  FLS  and  the  FLSS 


Assistance/Disaster  Relief  in  a  Coastal  Nation.”  Master’s  thesis,  Naval  Postgraduate 
School,  53. 


3.  Stakeholder  Analysis 

The  Unites  States  and  the  United  Nations  have  a  strategic  goal  of  maintaining 
stability  in  the  region.  A  lack  of  response  to  the  disaster  may  provide  a  catalyst  for  the 
increase  of  hostile  sentiment  towards  the  GOO  by  the  local  populous.  The  anti- 
government  forces  have  the  potential  to  increase  hostile  activities  by  instigating  the 
emotional  vulnerabilities  of  the  people.  The  U.S.  government  and  the  United  Nations 
provide  the  context  of  the  operation.  The  context  impacts  the  system,  but  the  system  does 
not  impact  the  context.  The  Unites  States  and  the  United  Nations  control  the  behavior  of 
the  system  by  issuing  strategic  guidance,  setting  rules  of  engagement,  and  relaying 
request  from  the  GOO.  They  can  also  set  strategic  requirements  for  the  system. 

Referring  back  to  Figure  38,  the  diagram  provides  a  general  idea  of  the  over 
concept  of  the  mission.  It  is  important  to  understand  the  arrow  with  the  two  heads 
because  it  signifies  the  interaction  between  the  system  and  the  external  system,  and  not 
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just  the  impact.  The  identification  of  which  functions  are  performed  by  specific 
components  and  how  the  system  interacts  with  the  external  system  are  conducted  during 
the  building  of  the  allocation  architecture.  The  interaction  between  the  two  systems  is 
non-observable  and  operational  validation  is  infeasible.  ICoMM  is  used  to  facilitate 
model  exploration  to  support  the  operational  validation  of  this  scenario. 

4.  Requirements  Analysis 

ICoMM  identifies  the  requirements  for  conducting  the  HA/DR  mission  from  the 
operational  concept.  The  requirements  products  identify  the  needs  of  the  stakeholders  of 
the  mission.  The  stakeholders  are  anyone  who  has  an  interest  in  the  decision  to 
participate  in  HA/DR,  execute  the  mission,  and  receive  aid  from  the  mission.  Three  levels 
of  requirements  are  identified  for  this  mission.  Figure  42  shows  the  requirements 
hierarchy  of  the  mission.  The  top  level  is  the  primary  requirement  for  the  system  is  to 
conduct  HA/DR  mission.  It  is  important  to  all  the  stakeholders  that  the  HA/DR  mission  is 
conducted.  The  HA/DR  requirement  provides  the  overall  requirement  of  the  mission.  All 
the  components  of  the  system  will  be  in  support  of  conducting  the  HA/DR  mission. 
ICoMM’ s  contribution  to  the  requirements  hierarchy  is  the  addition  of  the  external 
system’s  requirements.  It  is  important  to  identify  the  external  system’s  requirements 
because  it  has  a  direct  or  an  indirect  relationship  to  support  the  top-level  requirement. 


Figure  42.  Requirements  Hierarchy  for  the  HA/DR  Missions 
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The  HA/DR  requirement  is  supported  by  four  supporting  requirements  in  the  next 
level.  These  supporting  requirements  are  needed  to  achieve  the  primary  requirement. 
These  requirements  are  to  conduct  sea  base  operations,  air  transport,  connect  by  surface, 
and  receive  aid.  The  first  three  requirements  are  the  needs  of  the  HA/DR  mission  system 
while  the  last  requirement  is  the  need  of  the  external  system.  The  layout  of  the 
requirements  is  designed  to  show  not  only  the  requirement  of  the  system,  but  the  external 
system  as  well.  It  provides  the  stakeholders  a  graphic  display  of  how  the  needs  of  both 
systems  support  the  primary  requirement  of  conducting  the  HA/DR  mission.  The  lowest 
level  of  requirements  identified  in  the  system  is  to  support  the  second  level  requirements. 

The  requirements  of  conducting  C&C  and  logistical  operations  are  under  the 
requirement  of  conducting  sea  base  operations.  These  requirements  were  identified  to 
ensure  that  the  overall  functions  of  the  mission  had  oversight  and  resupply  was  conducted 
to  continue  the  operations  for  a  15  or  an  extended  60-day  mission.  C&C  is  a  subtask  of 
conducting  sea  base  operations.  It  is  responsible  for  overseeing  the  entire  HA/DR 
mission.  The  other  level  two  requirements  do  have  the  responsibility  of  this  requirement. 
The  sea  base  is  also  the  point  for  resupplying  the  units  participating  in  the  mission. 

There  are  two  requirements  to  deliver  aid  to  the  FLS  and  the  FLSS.  First, 
conducing  air  transport  requirement  is  needed  to  reach  the  FLSS  that  cannot  be  reached 
by  either  the  sea  or  surface  connectors.  The  requirements  that  support  the  air  connector 
requirements  are  to  provide  air  security  for  force  protection  (FP)  and  delivery  of  aid  to 
the  logistical  sites.  The  surface  connectors’  requirements  are  to  deliver  aid  to  the  FLS 
where  it  is  closer  to  the  water  inlets.  The  surface  connectors’  requirements  are  to  provide 
security  and  delivering  aid. 

The  last  level  2  requirement  is  to  receive  aid.  This  is  a  requirement  for  the  COO. 
The  people  of  Orange  must  be  able  to  receive  aid  for  the  mission  to  be  successful.  There 
is  also  a  level  3  requirement  to  provide  internal  security  against  the  anti-government 
forces. 
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D.  SYSTEM  ARCHITECTURE 


The  decomposition  of  the  system  occurs  during  the  architecting  phase.  The  three 
types  of  architecting,  functional,  physical,  and  allocated,  are  discussed  in  the  following 
sections.  Functional  architecture  is  created  to  facilitate  the  identification  of  the  attributes 
of  the  systems.  Physical  architecture  is  created  to  identify  all  the  components  of  the 
systems.  An  allocated  architecture  matches  the  functions  to  components.  Finally,  a  value 
model  is  built  to  identify  the  functions  that  SMEs  value  having  the  most  impact  during 
the  interaction  between  systems.  Turner  (2014)  addresses  these  functions  as  “impact 
variables”  in  his  research.  Again,  this  research  fills  the  gaps  Turner  identified  in  his 
previous  work  by  improving  the  identification  of  system  definition  and  the  structure  of 
conceptual  models  of  NOSs  for  validation. 

1.  Functional  Architecture 

The  functional  analysis  begins  once  the  requirements  have  been  identified.  It  is 
through  the  functions  that  the  requirements  for  the  systems  are  met.  Figure  43  shows  the 
functional  hierarch  of  the  HA/DR  system.  The  initial  functions  are  derived  from  the  Joint 
Tactics,  Techniques,  and  Procedures  for  Humanitarian  Assistance  doctrine  (Department 
of  Defense  2001).  ICoMM  identifies  that  sub-level  functions  not  mentioned  in  the  joint 
publication.  ICoMM  also  tailored  the  functional  architecture  in  Figure  42  to  include  the 
functions  of  the  external  system,  as  well  as  the  system,  but  exclude  the  function  that  is 
outside  of  the  scope  of  the  HA/DR  mission.  This  deviation  from  the  joint  doctrine 
supports  the  concept  of  this  dissertation  of  including  the  external  system  and  the  context 
in  the  design  of  the  system. 
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Figure  43.  Functional  Hierarchy 


The  overall  function  of  the  entire  system  is  to  provide  regional  stability.  Regional 
stability  is  maintained  by  the  next  level  2  functions.  They  provide  security,  HA/DR,  C&C 
and  infrastructure  repair.  Infrastructure  repair  is  blackened  because  it  will  not  be  a  part  of 
this  scenario.  No  HA/DR  mission  assets  are  dedicated  for  infrastructure  repair.  The 
external  system  function  of  perform  Country  Orange  functions  is  included  because  it 
supports  providing  regional  stability. 

2.  Enhanced  Functional  Flow  Diagrams 

As  described  in  Chapter  II,  the  EFFD  provides  another  view  of  the  functions 
compared  to  the  functional  hierarchy.  It  shows  the  sequence  of  the  functions  that  must  be 
executed.  The  sequence  of  the  functions  is  important  to  ICoMM  because  it  is  another  tool 
for  model  exploration  should  the  NOS  deviate  from  the  intended  output.  The  following 
diagrams  show  the  EFFD  for  the  sequence  of  functions  for  the  top  and  lower  level 
functions  as  examples. 
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a.  Provide  Regional  Stability 

Figure  44  shows  an  EFFD  to  provide  regional  security  to  illustrate  that  the  lower 
level  functions  are  conducted  simultaneously  as  noted  by  the  word  AND  in  a  white  circle. 
However,  the  external  system’s  function  is  depicted  on  separate  parallel  line.  The 
external  system’s  functions  will  be  performed  simultaneously,  but  not  as  part  of  the 
system.  It  will  support  the  overall  function  of  maintaining  regional  stability,  but  not  as  a 
part  of  the  system.  Again,  the  provide  infrastructure  function  is  blackened  because  it  is 
out  of  the  context  of  this  mission. 


Figure  44.  Provide  Regional  Stability  Functions 


Each  of  the  level  2  functions  are  supported  by  level  3  functions.  There  are  10  level  three 
functions  identified  in  this  study.  These  level  three  functions  establish  what  Parnell  calls 
objectives,  and  ultimately,  our  value  measurements  (Parnell,  Driscoll,  and  Henderson 
2011). 
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b.  Provide  Security  Function 

The  provide  security  function  is  one  of  two  functions  mentioned  in  JP3-07.6 
(200  f)  that  this  research  includes  as  a  level  2  function.  The  provide  security  has  two  level 
3  functions.  The  functions  are  to  provide  security  for  distribution  and  internal  FP.  The 
HA/DR  mission  is  aware  of  hostile  threats  in  the  area  and  must  provide  security  at  the 
FLS  and  the  FLSS  while  they  are  unloading  aid  at  the  sites.  Once  they  are  at  the  site,  it  is 
the  responsibility  of  the  HA/DR  unit  to  ensure  everyone’s  safety  at  the  site  in  conjunction 
with  the  local  security  forces.  The  crosswalk  of  functions  is  described  later  in  the  chapter 
to  demonstrate  how  level  3  functions  indirectly  support  other  level  2  functions.  The 
HA/DR  unit  is  also  responsible  for  providing  its  internal  force  protection.  This  function  is 
for  situations  when  the  connectors  are  at  neither  a  FLS  nor  a  FLSS.  The  two  functions 
may  also  be  conducted  simultaneously  due  to  the  continuing  nature  of  the  operation.  The 
green  and  grey  circles  represent  inputs  and  outputs  of  the  function.  It  is  discussed  further 
in  the  allocation  section  later  in  this  chapter.  Figure  45  outlines  the  security  functions. 


Figure  45.  Provide  Security  Functions 
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c.  Provide  HA/DR  Function 

The  HA/DR  function  is  the  other  level  2  function  mentioned  in  JP  3-07.6 
(Department  of  Defense  2006)  added  as  a  part  of  this  research.  It  is  the  function  that 
performs  the  primary  HA/DR  mission.  It  has  three  level  3  functions,  perform  air 
connector  functions,  perform  surface  connector  functions,  and  perform  forward  logistics 
functions.  The  EFFBD  shows  that  the  two-connector  functions  are  conducted  in  parallel 
while  the  forward  logistics  function  is  performed  following  the  two.  The  air  connector 
delivers  aid  by  aircraft  to  FLSS  when  other  transportation  means  from  the  sea  base  are 
not  possible.  The  surface  connector  function  delivers  aid  to  the  FLS  near  coastal  waters. 
The  forward  logistics  function  is  to  aid  the  flow  of  aid  from  the  HA/DR  mission  units  to 
the  local  population.  Figure  46  shows  the  flow  of  functions  to  provide  HA/DR. 


Figure  46.  Provide  HA/DR  Functions 


3.  Provide  Command  and  Control  Function 

The  C&C  function  has  two  level  3  functions.  The  C&C  has  two  functions,  receive 


supply  from  a  higher  logistical  station  and  perform  the  duties  as  a  sea  connector.  The 
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C&C  function  ensures  that  the  aid  for  the  population  of  the  COO  is  first  received  by  the 
sea  connectors  and  is  distributed  to  the  air  and  surface  connectors.  Figure  47  shows  the 
flow  of  functions  required  to  provide  C&C. 


Figure  47.  Provide  Command  and  Control  Functions 
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As  previously  mentioned,  the  functions  of  the  COO  are  of  the  external  system. 
However,  ICoMM  identifies  the  functions  of  the  COO  as  a  part  of  the  overall  function  of 
providing  regional  security.  There  are  three  level  3  functions  associated  with  the  COO: 
provide  internal  security  by  the  GOO,  receive  aid,  and  perform  hostile.  Functions  EXF.  1 
and  EXF.2  are  performed  in  parallel.  Function  EXF. 3  is  depicted  as  an  OR  in  a  white 
circle  to  show  that  it  is  a  function  performed  as  a  part  of  the  function  of  COO,  but  not  in 
conjunction  with  the  other  two.  The  allocated  architecture  presented  later  in  the  chapter 
shows  that  hostile  forces  opposing  the  GOO  also  has  functions  that  impact  the  system. 
Figure  48  shows  the  external  system’s  flow  of  functions,  specifically  for  the  COO. 
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Figure  48.  Provide  Country  of  Orange  Functions 


4.  Tracing  Functions  to  Requirements 

The  input  and  output  requirements  were  derived  from  the  requirements  identified 
in  section  C4.  The  inputs  are  needed  prior  to  the  execution  of  a  simulation  and  the 
outputs  are  the  results  of  post  simulation.  Table  4  shows  an  initial  list  of  input  and  output 
requirements  to  provide  traceability  of  functions.  The  input  and  output  requirements  also 
include  traceability  to  the  external  functions. 
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Table  4.  Traceability  from  Input  to  Output  Requirements  to  Functions 


Functions 

Input/Output  Requirement 

Input  Requirements 

Output  Requirements 

Functional 

Requirement 

External  Interface 
Requirement 

The  COO  will 
request  aid 

Hostile  Forces 
maybe  present 

The  HA/DR  mission 
will  deliver  Aid 

HA/DR  mission  will 
provide  internal 
security 

The  HA/DR  mission 
will  have  central 

C&C 

TheCOOwill 

contact  US  &  UN 
Reps  for  updates 

FUN  0.  Provide  Regional  Security 

X 

X 

X 

X 

X 

X 

FUN  1.  Provide  Security 

X 

X 

FUN  1.1  Provide  security  for  distribution 

X 

X 

FUN  1.2  Provide  Internal  Force  Protection 

X 

X 

FUN  2.  Provide  HA/DR 

X 

X 

FUN  2.1  Perform  Air  Connector 

X 

X 

X 

X 

FUN  2.2  Perform  Surface  Connector 

X 

X 

X 

X 

FUN  2.3  Perform  Forward  Logistics 

X 

X 

X 

X 

FUN  3.  Provide  Command  and  Command 

X 

X 

X 

FUN  3.1  Perform  Resupply  Functions 

X 

X 

FUN  3.2  Perform  Sea  Connector 

X 

X 

FUN  4.  Provide  Infrastructure  Repair 

EXFO,  Perform  Country  of  Orange 

X 

X 

EXF1,  Provide  Internal  Security 

X 

X 

EXF  2,  Receive  Aid 

X 

X 

EXF  3,  Perform  Hostile  Group  Functions 

X 

X 

5.  Physical  Architecture 

The  physical  architecture’s  purpose  is  to  identify  all  the  physical  components  that 
make  up  the  system.  ICoMM  also  identifies  the  components  of  the  external  system  to  be 
included  in  the  physical  architecture.  The  purpose  of  both  the  system  and  external  system 
components  are  to  meet  the  fundamental  objective  of  the  mission,  which  is  to  provide 
regional  security. 

Figure  49  shows  the  components  of  the  system  that  performs  the  functions  and  the 
relationships  of  the  components  to  each  other.  There  are  four  major  components  in  the 
system  and  three  in  the  external  system.  ICoMM  identifies  the  point  of  interaction 
between  the  two  systems.  The  point  of  interaction  is  important  because  it  is  where  the 
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two  systems  come  in  contact.  For  an  observable  system,  the  interaction  between  two 
systems  can  be  observed  and  data  can  be  collected.  However,  for  a  NOS,  the  interaction 
is  not  observable  and  no  data  is  available.  For  example,  the  flow  of  interaction  between 
the  components  of  the  system  can  be  observed  and  the  forecasted  output  in  sync  with  the 
actual  output.  However,  the  outcome  at  the  point  of  interaction  between  the  system  and 
the  external  system  is  less  predictable.  The  system  may  deliver  enough  aid  with  no  delay, 
but  the  reaction  of  the  people  may  not  be  as  forecasted. 


Figure  49.  Physical  Architecture  and  the  Point  of  Interaction 


The  physical  architecture  also  has  a  physical  hierarchy  that  describes  the 
hierarchy  of  the  components.  The  MEU  assigned  to  the  HA/DR  mission  includes  various 
platforms  to  perform  the  required  functions.  The  MEU  includes  three  different 
amphibious  warships  serving  as  sea  connectors;  LHD,  LPD,  and  the  LSD.  There  is  one  of 
each  class  on  the  amphibious  ships.  Each  of  the  ships  also  either  carries  air  connectors, 
surface  connectors,  or  both.  The  air  connectors  include  a  MH53  transport  helicopter,  a 
SH60  medium  utility  helicopter,  and  a  MV-22  tilt-rotor  transport.  The  purpose  of  the  air 
connectors  is  to  deliver  aid  to  the  FLSS  that  are  remote  and  far  away  from  access  to  the 
sea.  The  surface  connectors  include  LCAC  and  LCU.  The  purpose  of  the  surface 
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connector  is  to  deliver  aid  to  the  FLS  within  proximity  of  the  sea.  Figure  50  graphically 
outlines  the  distribution  of  vehicles  among  the  sea  connectors. 


Figure  50.  Distribution  of  Air  and  Surface  Connectors  among  the  Amphibious 
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ICoMM  identifies  the  external  physical  architecture  as  the  composition  of  the 
people  of  COO,  GOO,  and  hostile  forces.  As  seen  in  Figure  51,  both  the  GOO  and  the 
hostile  forces  converge  on  the  people  of  Orange.  The  system  also  interacts  with  the 
people.  The  convergence  to  one  component  has  a  strong  indication  that  this  is  the  center 
of  gravity  of  the  operation.  Conceptual  planning  of  the  center  of  gravity  and 
understanding  how  it  impacts  the  overall  mission  is  an  important  aspect  of  military 
operations  (Department  of  the  Army  2014).  The  military  center  of  gravity  is  defined  by 
JP  5-0  as  “a  source  of  power  that  provides  moral  or  physical  strength,  freedom  of  action, 
or  will  to  act”  (Department  of  Defense  2011,  III— 22).  Identification  of  the  military  center 
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of  gravity  is  important  in  this  scenario  because  it  provides  better  insight  into  the  selection 
of  the  point  of  interaction.  The  identification  of  the  military  center  of  gravity  also 
supports  the  idea  that  the  hostile  forces  conduct  its  operations  to  influence  the  population 
to  turn  against  the  GOO. 


Figure  51.  Components  of  the  External  System 


6.  Allocated  Architecture 

The  allocated  architecture  provides  the  overall  picture  of  the  complete  system.  As 
previously  mentioned,  the  external  system  is  also  included  to  show  the  interaction  with 
the  system.  The  functional  and  physical  architectures  previously  discussed  are  the  basis 
for  the  building  of  the  allocated  architecture.  The  functions  identified  on  the  functional 
hierarchy  are  linked  to  the  components  in  the  physical  architecture. 

The  traceability  provided  by  the  allocated  architecture  is  shown  on  an  IDEFO 
model.  The  IDFEO  model  uses  the  functional  and  physical  decompositions  to  assign  to 
the  components  to  the  functions.  The  link  is  made  at  every  level.  The  IDEFO  model 
describes  not  only  the  link  between  the  component  and  the  function  but  also  the  inputs 
and  outputs  of  the  model,  as  well  as  the  controls  the  functions  will  be  performing.  The 
IDEFO  model  has  four  main  components:  inputs,  control,  outputs,  and  mechanisms  to 
describe  system.  Figure  52  shows  the  highest-level  IDEFO  diagram  supporting  the 
fundamental  objective  of  providing  regional  security.  As  seen  in  the  functional  hierarchy, 
five  sub-level  functions  must  be  accomplished  to  meet  the  fundamental  objective. 
Function  4,  provide  infrastructure  repair,  is  not  included  in  this  research  because  it  is 
outside  of  the  scope  of  the  military’s  HA/DR  mission.  All  the  other  functions  are  part  of 
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the  HA/DR  mission  to  include  the  external  function.  The  mechanism  or  the  component 
that  executes  the  functions  one  through  three  is  the  HA/DR  mission  or  also  known  as  the 
HA/DR  mission  unit.  The  external  system,  EXF.O  perform  COO  functions,  also  has  the 
HA/DR  mission  that  provides  support  to  the  function.  However,  the  primary  component 
to  EXF.O  is  the  GOO.  All  the  components  of  the  system  are  controlled  by  the  disaster 
relief-operating  guide  from  the  DOD  and  at  the  request  of  the  COO.  This  is  scope  of  the 
HA/DR  mission  the  MEU  will  be  executing.  The  following  sections  discuss  each  of  the 
IDEFO  components  in  greater  detail. 
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The  provide  security  section  has  two  level  2  functions.  Figure  53  shows  that  two 
functions  are  to  provide  security  for  the  distribution  of  aid  and  internal  protection.  The 
functions  are  executed  by  the  components  of  the  overall  HA/DR  mission  and  by  both  the 
surface  connector  and  air  connector.  These  components  perform  both  security  and 
internal  FP  throughout  the  HA/DR  mission.  Both  security  and  internal  FP  functions  are 
performed  because  the  connectors  carry  FP  personnel  during  the  execution  of  the 
missions.  Once  they  reach  their  destinations  of  either  FLS  or  FLSS,  the  personnel  of  the 
connectors  provide  security  during  the  distribution  of  aid  in  conjunction  with  the  country 
of  Orange  security  forces  (COSF).  The  control  portion  of  the  provide  security  IDEFO  is 
following  the  disaster  relief  guide,  which  provides  guidance  during  the  execution  of  the 
HA/  DR  mission.  ICoMM  uses  the  control  of  the  IDEFO  as  providing  the  context  by 
defining  the  scope  and  boundary  of  their  mission.  Ultimately,  the  C&C  element  oversees 
the  functions  of  security  and  FP.  Any  changes  in  their  state  are  reported  to  the  sea  base  to 
measure  progress.  The  input  for  FUN.  1.1  is  an  unsecured  area  and  the  output  is  a  secured 
area.  The  input  for  FUN.  1 .2  is  the  state  of  security  during  the  operation  and  the  output  is 
that  FP  is  maintained.  It  is  also  to  note  that  the  output  of  FP  also  provides  an  input  for 
FUN.  1.1.  It  is  because  the  level  of  FP  has  an  effect  on  the  security  during  the  distribution 
of  aid.  Should  the  level  of  FP  be  at  a  level  where  the  connectors  could  not  protect  it  from 
the  enemy,  then  the  mission  would  have  to  be  altered  to  meet  the  requirement  to  provide 
security. 
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Figure  53.  IDEFO  Diagram  of  Provide  Security 


7.  Provide  HA/DR 

The  provide  HA/DR  function  has  three  level  2  functions.  The  functions  of 
perform  air  connector  missions,  perform  surface  connector  missions  and  to  perform 
forward  logistics  are  previously  identified.  The  functions  are  all  controlled  by  the  disaster 
relief  operating  guide.  However,  the  C&C  of  the  mission  provide  context  to  only  two  of 
the  functions  as  a  mean  of  control.  There  are  also  only  one  input  to  each  of  the  functions, 
the  aid  and  supplies  of  the  mission.  Both  of  the  connectors  receive  aid  supplies  from  the 
sea  base  and  perform  their  functions  to  deliver  the  aid  supplies  to  the  FLS  and  FLSS.  The 
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aid  delivered  by  the  connectors  is  the  inputs  to  perform  forward  logistics  and  the  output  is 
the  distribution  of  the  aid  supplies  to  the  local  population.  The  mechanisms  assigned  to 
perform  the  air  connector  functions  are  the  MH  53,  MV22  and  the  SH60  aircrafts.  They 
are  responsible  for  carrying  the  aid  supplies  to  the  FLSS.  The  mechanisms  executing  the 
surface  connector  functions  are  the  LCAC  and  the  LCU.  The  surface  connectors  deliver 
aid  to  the  FLS.  The  actual  FLS  and  the  FLSS  performs  the  functions  of  the  forward 
logistics  to  ensure  the  flow  of  aid  supplies  from  the  connectors  are  distributed  to  the  local 
population.  Figure  54  shows  the  1DEF0  model  that  traces  the  1COM. 


Figure  54.  1DEF0  Diagram  for  Provide  HA/DR 
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a.  Provide  Command  and  Control 

Figure  55  shows  the  IDEFO  model  for  the  C&C  function.  There  are  two  level  2 
functions  that  support  the  C&C  function,  perform  resupply  functions  as  the  sea  base  and 
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perform  sea  connector  function.  The  LHD,  the  LPD,  and  the  LSD  amphibious  ships 
perform  both  functions.  Both  inputs  are  the  resupply  from  resupply  ships  that  are  for  both 
internal  supply  needs  and  to  distribute  to  the  COO. 


Figure  55.  IDEFO  Diagram  for  Provide  Command  and  Control 
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b.  Perform  Country  of  Orange  Functions 

ICoMM  also  investigated  the  IDEFO  model  of  the  external  system  as  we  did  of 
the  system.  The  IDEFO  model  for  the  external  system  is  shown  in  Figure  56.  An  IDEFO 
model  must  also  be  made  for  the  external  system  to  understand  its  functions  and  the 
components  that  will  execute  the  external  system  functions.  The  external  system’s  overall 
function  of  performing  COO  functions  has  three  sub-level  functions:  provide  internal 
security  for  the  GOO,  receive  aid,  and  perform  hostile  group  functions.  The  functions 
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were  described  in  detail  previously  in  section  B 1  of  this  chapter.  The  following  sections 
discuss  the  allocation  of  the  sub-level  functions  to  the  components  in  greater  detail. 


Figure  56.  IDEFO  Diagram  of  Perform  Country  of  Orange  Functions 


c.  Provide  Internal  Security 

The  first  external  system  function  is  to  provide  internal  security.  The  GOO 
executes  this  function.  Figure  57  shows  the  controls  for  this  function  are  the  UN  and  U.S. 
negotiations  to  assist  the  COO  and  the  internal  laws  of  the  country.  The  UN  and  U.S. 
organizations  establish  the  scope  and  boundary  of  the  actions  of  the  HA/DR  mission  unit, 
as  well  as  the  expectation  of  the  GOO,  while  the  law  governing  the  country  limits  the 
actions  of  its  internal  forces.  The  inputs  are  the  actions  of  the  HA/DR  mission  of 
conducting  relief  and  providing  a  secure  area.  The  output  of  this  function  is  the  state  of 
the  country.  The  state  of  the  country  may  be  on  pace  to  a  quick  recovery  or  recovery  may 
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be  delayed  due  to  an  increase  of  hostile  activities.  The  state  of  the  country  is  an  indicator 
measured  to  provide  information  to  the  stakeholders  to  refine  and  execute  plans  based  on 
the  state  of  the  country. 


Figure  57.  IDEFO  Diagram  for  Provide  Internal  Security  (GOO)  Functions 
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d.  Receive  Aid 

The  following  external  system  function  is  to  receive  aid,  as  seen  in  Figure  58.  As 
simple  as  it  may  sound,  it  is  important  to  maintain  a  good  measure  of  the  amount  of  aid 
flowing  into  the  FLS  and  the  FLSS  by  the  HA/DR  mission  unit.  Therefore,  the  inputs  into 
this  function  are  the  deliver  mechanisms,  the  disaster  area,  and  the  state  of  both  the 
security  and  overall  country.  The  output  is  the  aid  supplies  distributed  to  the  people.  The 
component  that  receives  the  aid  is  the  local  population.  A  secure  area  and  the  distribution 
of  supplies  control  the  function. 
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Figure  58.  IDEFO  Diagram  for  Receive  Aid 


8.  Perform  Hostile  Group  Functions 

As  previously  mentioned,  the  hostile  forces  are  also  components  that  influence  the 
HA/DR  mission.  Figure  59  shows  perform  hostile  functions  conducted  by  the  hostile 
forces  within  the  COO.  It  is  controlled  by  the  distribution  of  aid  supplies  by  the  HA/DR 
mission  units.  The  hostile  group  forces  must  act  if  the  amount  of  distribution  increases.  If 
the  amount  of  distribution  decreases,  then  the  actions  of  the  group  may  have  had  success 
in  their  efforts.  The  inputs  are  the  delivery  of  aid  from  both  air  and  sea  connectors.  It  also 
includes  whether  disaster  relief  was  conducted.  Performing  hostile  group  acts  on  the 
inputs  produces  increases  anti-government  sentiments.  This  action  must  be  monitored 
due  to  its  effect  of  reaching  the  fundamental  objective  of  providing  regional  security. 
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Figure  59.  IDEFO  Model  for  Perform  Hostile  Group  Functions 
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E.  ESTABLISHING  THE  VALUE  OF  THE  ALLOCATED  FUNCTIONS 

ICoMM  equates  the  top-level  function  as  the  “fundamental  objective”.  The 
fundamental  objective  is  the  overall  strategic  mission  to  provide  regional  security. 
“Means  objectives”  or  sub-level  objectives  also  support  the  listed  functions.  The  means 
objectives  show  the  preferences  regarding  the  values  intended  by  the  stakeholders 
(Parnell,  Driscoll,  and  Henderson  2011).  The  following  values  are  the  means  objectives 
that  are  the  quantitative  method  to  evaluate  the  system  performance  and  identify 
progression  of  the  system  toward  the  achievement  the  fundamental  objective.  The 
structure  shown  in  Table  4  is  the  basis  for  measures  of  effectiveness  and  measure  of 
performance  (MOP)  in  military  operational  assessment  process.  Tables  5  and  6  show  the 
value  hierarchy  for  the  system  and  the  external  system.  The  table  lists  the  top-level 
function.  As  previously  mentioned,  the  top-level  function  is  also  the  fundamental 
objective  of  the  HA/DR  mission.  The  two  rows  below  are  the  level  2  and  level  3 

functions.  The  following  rows  alternate  between  means  objectives  and  the  measures.  The 

100 


means  objective  show  whether  the  values  should  be  maximized  or  minimized.  The 
measures  directly  below  the  means  objectives  show  the  measures  that  must  be  taken  to 
show  status  of  the  mission.  Table  5  shows  means  objectives  and  the  measures  for  the 
system.  It  is  listed  under  the  systems  functions.  Each  column  represents  the  direct  support 
of  objectives  and  measures  to  the  functions  above. 


Table  5.  System  Means  Objectives  and  its  Measures 


FUN  0.  Provide  Regional  Security 

FUN  1,  Provide  Security 

FUN  2.  Provide  HA/DR 

FUN  3,  Provide  Command  and  Control 

FUN  1,1  Provide  security  for  distribution 

FUN  1,2  Provide  Internal  Force  Protection 

FUN  2,1  Perform  Air  Connector 

FUN  2,2  Perform  Surface  Connector 

FUN  2,3  Perform  Forward  Logistics 

FUN  3,1  Perform  Resupply  Functions 

FUN  3,2  Perform  Sea  Connector 

FUN  1,11  Max  number  of  troops 

FUN  1,2,1,  Max  number  of  troops 

FUN  2,1,1,  Max  number  of  air  frames 

FUN  2,2,1,  Max  number  of  surface  vehicles 

FUN  2,3,1,  Max  amount  of  aid  flow 

FUN  3,1,1,  Max  amount  of  resupply 

FUN  3,2,1,  Max  command  and  control 

Number  of  troops  by  specialty 

Number  of  troops  by  specialty 

Number  of  different  aircrafts  (type| 

Number  of  different  surface  crafts  (type] 

Amound  of  aid  into  FLS &FLSS  (lbs/type| 

Amount  of  resupply  (lbs/type| 

No  loss  of  contact  with  deployed  element 

Fun  1,1,2,  Max  number  of  equipment 

FUN  1,2,2,  Max  number  of  equipment 

FUN  2,1,2,  Max  number  of  aid  flow 

FUN  2,2,2,  Max  number  of  aid  flow 

FUN  2,3,2,  Max  amount  of  storage 

FUN  3,1,2,  Max  amount  of  storage 

FUN3, 2, 2, Max  contact  with  Govt  of  Orange 

Number  of  equipment  by  type 

Number  equipment  by  type 

Amount  of  aid  delivered  per  day  |lbs| 

Amount  of  aid  delivered  per  day  (lbs) 

Amount  of  aid  stored  (lbs/type| 

Amount  of  stored  (lbs/type| 

Number  of  contact  with  GOO 

FUN2.1.3.Mai(  Payload 

FUN  2,2,3,  Max  Payload 

FUN  2,3,3,  Max  distribution 

Amount  of  payload  (lbs| 

Amount  of  payload  (lbs| 

Amount  of  aid  distributed  (Ibs/type) 

FUN  2,1,4,  Min  travel  time 

FUN  2,2,4,  Min  travel  time 

Travel  time  (kpb| 

Travel  time  (mph) 

FUN  2,1,5,  Min  fuel  usage 

FUN  2, 2, 5, Min  fuel  usage 

Amount  of  fuel  used  (gal /hr) 

Amount  of  fuel  used  (gal  /hr) 

FUN  2,1,6,  Min  load  time 

FUN  2,2,6,  Min  load  time 

Time  to  load  aircraft  |min| 

Time  to  load  surface  craft  (min| 

FUN  2,1,7,  Min  unload  time 

FUN  2, 2, 7, Min  unload  time 

Time  to  unload  aircraft  (min| 

Time  to  unload  surface  craft  (min| 

FUN  2,1,8,  Max  operating  time 

FUN  2,2,8,  Max  operating  time 

Time  to  operate  aircraft  (fit  hrs| 

Time  to  operate  surface  craft  (fit  hrs) 

FUN  2.1.9.  Max  number  of  trips  to  FLSS 

FUN  2.2.9.  Max  number  of  trips  to  FLS 

Number  of  trips 

Number  of  trips 

n  Functions 

0  Value  Measures 

Table  6  shows  the  means  objectives  and  the  measures  for  the  external  system.  The 
functions  for  the  COO  support  primarily  the  requirement  of  receiving  aid,  as  seen  in  the 
requirements  hierarchy.  In  the  functional  hierarchy,  the  function  of  receiving  aid  supports 
the  higher  function  of  performing  the  function  of  the  COO  along  with  providing  internal 
security  and  performing  hostile  group  functions.  An  example  can  be  seen  in  Figure  42. 
The  means  objectives  and  the  measures  support  the  functions  of  the  three  level  3 
functions,  which  support  the  functions  of  the  COO. 
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Table  6.  External  Systems  Means  Objectives  and  Measures 


FUN  0.  Provide  Regional  Security 


EXF  0.  Perform  Country  of  Orange 

EXF  1.  Provide  Internal  Security 

EXF  2.  Receive  Aid 

EXF  3.  Perform  Hostile  Group  Functions 

EXF  1.1.  Max  Security  forces 

EXF  2.1.  Max  Aid  received 

EXF  3.1. Max  number  of  anti-govt  forces 

Number  of  security  force  troops 

Amount  of  aid  (lbs  /  type) 

Number  of  anti-govt  forces 

EXF  1.2.  Max  Distribution  of  COSF  to  FLS  &FLSS 

EXF  2.2.  Max  aid  distributed  to  population 

EXF  3.2.  Max  attack  on  govt  facilities 

Number  of  security  forces  at  FLS  &  FLSS 

Amount  distributed  (lbs  /  type) 

Number  of  attacks 

EXF  1.3.  Max  interaction  with  local  population 

EXF  2.3.  Min  distance  poulation  travel 

EXF  3.3.  Max  prevention  of  aid  to  population 

Number  of  engagements  with  population 

Distance  traveled  to  receive  aid  (miles) 

Number  of  attacks 

EXF  1.4.  Max  interaction  with  hostile  forces 

EXF  2.4  Max  contact  with  HA/DR  unit 

EXF  3.4.  Max  interaction  with  local  population 

Number  of  engagements  with  hostile  forces 

Number  of  contacts  with  HA/DR  unit 

Number  of  contact  with  local  population 

EXF  1.5  Min  casulaties 

EXF  3.5.  Min  attack  on  population 

Number  of  casualties 

Number  of  attacks 

EXF  3.6.  Min  interaction  with  Govt  Forces 

Number  of  engagements  with  GOO 

EXF  3.7.  Min  casualties 

Number  of  casualites 

P  |  Functions 
□  Value  Measures 


Figure  60  is  a  crosswalk  of  the  measures  to  functions  to  the  objectives,  and 
ultimately,  to  the  fundamental  objective.  The  objectives  are  lined  up  below  the  functions 
it  supports.  The  arrows  depict  the  different  functions  that  objectives  may  have  an  effect 
on  other  objectives.  For  example,  objective  2.1.3  maximizes  the  amount  of  payload  by 
aircraft,  which  directly  supports  the  perform  air  connection  function  that  has  an  effect  on 
the  function  of  performing  forward  logistics.  The  inability  of  the  air  connectors  to  deliver 
maximum  payload  of  aid  to  the  forward  logistics  sites  will  hinder  the  forward  logistics 
functions  and  not  obtain  the  means  objectives  of  maximizing  the  amount  of  storage  and 
distribution  of  good  to  the  local  population.  It  also  affects  the  external  system  and  its 
function  of  receiving  aid.  The  lack  of  aid  delivered  to  the  population  of  Orange  could 
potentially  assist  hostile  groups,  and  ultimately,  have  an  inverse  effect  on  the 
fundamental  objective  of  providing  regional  security.  It  is  important  to  identify 
adversarial  functions  and  crosswalk  the  measures  that  have  the  possibility  of  hindering 
the  success  of  the  operation. 
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Figure  60.  Crosswalk  of  the  Means  Objectives  to  the  Functions 


SMEs  are  solicited  to  provide  their  value  of  the  different  measures  after 
performing  the  cross  walk  between  the  objectives  and  functions.  The  inputs  from  the 
SMEs  demonstrate  the  values  they  feel  are  important  to  the  mission.  The  result  of  this 
process  will  capture  the  most  important  functions  and  objectives  for  the  system  (Parnell, 
Driscoll,  and  Henderson  2011).  The  measures  are  also  weighted  to  show  the  potential 
impact  the  function  will  have  on  the  overall  mission.  The  DM  is  the  commander  of  the 
mission  and  relies  on  SMEs  to  provide  weights  to  the  best  of  their  knowledge. 

Table  7  is  an  example  of  the  solicitation  taken  from  the  SMEs  of  the  troops 
dedicated  for  FP.  The  number  of  troops  dedicated  FP  purposes  is  759.  A  third  of  the 
2,300  total  troops  for  the  mission  are  dedicated  to  FP.  The  stakeholder  is  provided  with  a 
degradation  of  troops  in  10%  increments  from  the  maximum  for  a  protection  number  of 
759.  The  stakeholder  is  asked  to  rate  the  values  from  0  to  100.  The  numbers  do  not  have 
to  be  in  increments  of  10.  The  table  shows  that  there  is  a  large  drop  in  value  when  the 
number  of  troops  drops  from  380  to  304.  The  number  of  troops  at  380  is  50%  from  the 
maximum  force  and  the  stakeholder  indicates  that  the  force  may  not  be  able  to  operate 
below  380. 
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Table  7.  Example  of  Troops  for  Force  Protection  Value  Solicitation  from 

Stakeholders 


Troops  for  Force  Protection 

Value 

759 

100 

683 

95 

607 

90 

531 

87 

455 

76 

380 

70 

304 

50 

228 

30 

152 

20 

76 

0 

The  information  Table  7  can  also  be  depicted  in  a  graphical  manner.  Figure  61 
shows  a  concave  graph  describing  a  decrease  from  an  optimal  number  of  troops  to  the 
least  desirable  number.  All  the  value  measure  graphs  are  monotonically  increasing  or 
decreasing.  The  importance  of  the  graph  is  that  a  DM  or  any  other  stakeholders  can 
quickly  assess  the  situation  and  make  decisions  based  on  the  predetermined  points  of 
decision.  These  are  identified  on  the  inflection  points  circled  on  the  graph.  The  first 
inflection  point  is  at  value  87  when  the  mission  has  taken  a  loss  of  30  percent  for  the 
troops  for  the  FP  measure.  The  second  inflection  point  is  at  value  70  when  there  is  a  50% 
loss  of  troops.  This  number  would  be  a  warning  sign  to  the  commander  to  either  choose  a 
different  course  of  action  or  begin  requesting  replacements.  The  number  of  troop  loss  is 
not  only  for  contact  loss  but  also  due  to  sickness  or  other  administrative  issues. 
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Figure  61.  Value  Measure  Number  of  Troops  for  Force  Protection 


Troops  for  FP 


Looking  back  at  the  objectives  to  functions  crosswalk,  ICoMM  identified  that 
objective  1.2.1,  maximize  number  of  troops  for  FP,  also  have  indirect  effects  on  functions 
perform  air  connector  and  perform  surface  connector.  The  decrease  of  the  number  of 
troops  for  force  protection  has  the  potential  to  inhibit  the  two-connector  functions.  The 
cross  walk  is  shown  in  Figure  62. 


Figure  62.  Maximize  Number  of  Troops  for  Force  Protection  Objective 

Crosswalk 
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After  tracing  the  potential  impact  of  the  decrease  of  the  number  of  troops  for  FP 
to  perform  air  connector,  we  will  take  a  look  at  one  of  the  air  connector  objectives  that 
may  potentially  affect  it.  The  objective  is  to  maximize  the  number  of  aircraft  that  will  be 
involved  in  the  HA/DR  mission.  A  total  of  24  aircrafts  will  be  participating  in  the 
mission.  The  number  of  aircraft  that  can  be  flown  in  the  mission  is  also  dependent  on  the 
amount  of  FP  troops  available  to  provide  security.  The  reduction  of  FP  troops  also  means 
a  reduction  in  participating  aircrafts.  The  decrease  in  the  value  is  based  on  each  aircraft 
loss.  The  inflection  point  is  at  value  8.4  with  the  loss  of  four  aircrafts.  The  loss  of  an 
aircraft  could  be  due  to  normal  maintenance  or  loss  during  operation.  Anything  below  the 
loss  of  four  aircrafts  will  not  be  acceptable  to  the  commander,  as  shown  in  Figure  63. 

Figure  63.  Value  Measure  of  Number  of  Aircrafts  for  HA/DR  Mission 

Number  of  Aircrafts 


Once  all  the  value  measures  are  identified  and  graphed,  global  weights  are 
assigned  to  the  measures.  The  global  weights  enable  the  SMEs  to  identify  the  objectives 
they  feel  will  have  the  most  impact  during  the  operation.  While  all  the  measures  are 
tracked,  the  ones  with  greater  weights  receive  greater  emphasis.  Table  8  shows  the 
functions,  objective,  measure,  the  swing  weights,  and  the  global  weights.  The  swing 
weights  were  solicited  again  from  the  SMEs  to  rate  all  the  measures.  The  global  weight 
measures  also  show  the  importance  of  the  measure. 
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Table  8.  Ordering  of  the  Value  and  the  Impact  of  the  Functions 


FUNCTION 

OBEJECTIVE 

MEASURE 

SWING 

GLOBAL 

NORM  SCORE 

FUN  1.  Provide  Security 

FUN  1.1  Provide  security  for  distribution 

FUN  1.1.1.  Max  number  of  troops 

Number  of  troops  by  specialty 

64 

0.0198 

1.39 

FUN  1.1.2.  Max  number  of  equipment 

Number  of  equipment  by  type 

63 

0.0195 

FUN  1.2  Provide  Internal  Force  Protection 

FUN  1.2.1.  Max  number  of  troops 

Number  of  troops  by  specialty 

62 

0.0192 

FUN  1.2.2.  Max  number  of  equipment 

Number  equipment  by  type 

61 

0.0189 

FUN  2.  Provide  HA/DR 

FUN  2.1  Perform  Air  Connector 

FUN  2.1.1.  Max  number  of  air  frames 

Number  of  different  aircrafts  (type) 

100 

0.0309 

2.03 

FUN  2.1.2.  Max  number  of  aid  flow 

Amount  of  aid  delivered  per  day  (lbs) 

95 

0.0294 

FUN  2.1.3.  Max  Payload 

Amount  of  payload  (lbs) 

93 

0.0288 

FUN  2.1.4.  Min  travel  time 

Travel  time  (kph) 

85 

0.0263 

FUN  2.1.5.  Min  fuel  usage 

Amount  of  fuel  used  (gal  /  hr) 

90 

0.0278 

FUN  2.1.6.  Min  load  time 

Time  to  load  aircraft  (min) 

87 

0.0269 

FUN  2.1.7.  Min  unload  time 

Time  to  unload  aircraft  (min) 

86 

0.0266 

FUN  2.1.8.  Max  operating  time 

Time  to  operate  aircraft  (fit  hrs) 

89 

0.0275 

FUN  2.1.9.  Max  number  of  trips  to  FLSS 

Number  of  trips 

97 

0.0300 

FUN  2.2  Perform  Surface  Connector 

FUN  2.2.1.  Max  number  of  surface  vehicles 

Number  of  different  surface  crafts  (type) 

84 

0.0260 

1.79 

FUN  2.2.2.  Max  number  of  aid  flow 

Amount  of  aid  delivered  per  day  (lbs) 

99 

0.0306 

FUN  2.2.3.  Max  Payload 

Amount  of  payload  (lbs) 

81 

0.0251 

FUN  2.2.4.  Min  travel  time 

Travel  time  (mph) 

70 

0.0217 

FUN  2.2.5.Min  fuel  usage 

Amount  of  fuel  used  (gal  /  hr) 

74 

0.0229 

FUN  2.2.6.  Min  load  time 

Time  to  load  surface  craft  (min) 

73 

0.0226 

FUN  2.2.7.Min  unload  time 

Time  to  unload  surface  craft  (min) 

71 

0.0220 

FUN  2.2.8.  Max  operating  time 

Time  to  operate  surface  craft  (fit  hrs) 

75 

0.0232 

FUN  2.2.9.  Max  number  of  trips  to  FLS 

Number  of  trips 

83 

0.0257 

FUN  2.3  Perform  Forward  Logistics 

FUN  2.3.1.  Max  amount  of  aid  flow 

Amound  of  aid  into  FLS  &FLSS  (Ibs/type) 

98 

0.0303 

1.74 

FUN  2.3.2.  Max  amount  of  storage 

Amount  of  aid  stored  (Ibs/type) 

69 

0.0213 

FUN  2.3.3.  Max  distribution 

Amount  of  aid  distributed  (Ibs/type) 

68 

0.0210 

FUN  3.  Provide  Command  and  Control 

FUN  3.1  Perform  Resupply  Functions 

FUN  3.1.1.  Max  amount  of  resupply 

Amount  of  resupply  (Ibs/type) 

67 

0.0207 

1.61 

FUN  3.1.2.  Max  amount  of  storage 

Amount  of  stored  (ibs/type) 

66 

0.0204 

FUN  3.2  Perform  Sea  Connector 

FUN  3.2.1.  Max  command  and  control 

No  loss  of  contact  with  deployed  element 

92 

0.0285 

FUN  3.2.2.  Max  contact  with  Govt  of  Orange 

Number  of  contact  with  GOO 

65 

0.0201 

EXF  0.  Perform  Country  of  Orange 

EXF  1.  Provide  Internal  Security 

EXF  1.1.  Max  Security  forces 

Number  of  security  force  troops 

55 

0.0170 

1.20 

EXF  1.2.  Max  Distribution  of  COSF  to  FLS  &FLSS 

Number  of  security  forces  at  FLS  8i  FLSS 

54 

0.0167 

EXF  1.3.  Max  interaction  with  local  population 

Number  of  engagements  with  population 

53 

0.0164 

EXF  1.4.  Max  interaction  with  hostile  forces 

Number  of  engagements  with  hostile  forces 

52 

0.0161 

EXF  1.5  Min  casulaties 

Number  of  casualties 

56 

0.0173 

EXF  2.  Receive  Aid 

EXF  2.1.  Max  Aid  received 

Amount  of  aid  (lbs  /  type) 

96 

0.0297 

1.66 

EXF  2.2.  Max  aid  distributed  to  population 

Amount  distributed  (lbs  /  type) 

92 

0.0285 

EXF  2.3.  Min  distance  poulation  travel 

Distance  traveled  to  receive  aid  (miles) 

50 

0.0155 

EXF  2.4  Max  contact  with  HA/DR  unit 

Number  of  contacts  with  HA/DR  unit 

60 

0.0186 

EXF  3.  Perform  Hostile  Group  Functions 

EXF  3.1.Max  number  of  anti-govt  forces 

Number  of  anti-govt  forces 

49 

0.0152 

1.13 

EXF  3.2.  Max  attack  on  govt  facilities 

Number  of  attacks 

59 

0.0183 

EXF  3.3.  Max  prevention  of  aid  to  population 

Number  of  attacks 

58 

0.0179 

EXF  3.4.  Max  interaction  with  local  population 

Number  of  contact  with  local  population 

40 

0.0124 

EXF  3.5.  Min  attack  on  population 

Number  of  attacks 

57 

0.0176 

EXF  3.6.  Min  interaction  with  Govt  Forces 

Number  of  engagements  with  GOO 

46 

0.0142 

EXF  3.7.  Min  casualties 

Number  of  casualites 

48 

0.0149 

TOTAL= 

r  3232 

1.0000 

F.  SUMMARY 

This  chapter  presented  a  proof  of  concept  of  the  application  of  ICoMM  by 
applying  SE  and  SA  processes  to  build  a  conceptual  model  of  a  HA/DR  scenario.  The 
incorporation  of  SMEs  values  and  improved  structure  demonstrated  that  ICoMM  can 
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facilitate  face  and  traces  validation  techniques.  It  also  identified  methods  for  supporting 
the  operational  validation  of  a  NOS  by  model  exploration.  The  inclusion  of  SE  methods 
in  the  MDP  facilitated  the  identification  of  requirements,  functional,  and  physical 
analysis.  The  analysis  was  conducted  simultaneously  for  the  system  and  the  external 
system  to  demonstrate  potential  interaction  between  the  two  systems.  The  operational 
behaviors  of  the  interactions  are  not  directly  observable.  It  is  important  to  note  that  the 
functions  of  both  systems  affect  each  other  in  some  way  and  the  SMEs  values  of  these 
functions  must  be  documented  during  the  building  of  the  CoM.  Therefore,  it  is  important 
that  a  clearly  traceable  CoM  is  created  prior  to  the  execution  of  a  simulation  to  minimize 
the  uncertainty  produced  by  the  interaction  of  the  two  systems.  ICoMM  ensures  that  this 
information  is  available  during  the  model  exploration  of  a  NOS. 
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V.  CONCLUSION 


A.  SUMMARY 

This  research  demonstrated  the  importance  of  an  improved  structure  of  the  CoM 
for  validation  to  gain  greater  trust  by  the  DMs.  A  secondary  result  was  gained  by  a 
greater  understanding  of  the  application  of  SE  and  SA  processes  to  improve  the  structure 
of  CoMs.  ICoMM  addresses  the  difficulty  of  operationally  validating  systems  classified 
as  non-observable  that  can  be  improved  by  designing  the  CoM  early  in  the  MPD  with 
facilitated  early  SME  involvement  and  a  structure  that  logically  connects  the 
measurements  to  the  fundamental  objective. 

The  most  recent  research  into  this  domain  lacked  structure  to  demonstrate  clear 
traceability  from  the  measures  of  performance  and  effectiveness  to  the  fundamental 
objective.  This  research  demonstrated  that  the  application  of  SE  processes  to  decompose 
systems  and  build  models  of  the  systems  by  applying  SA  techniques  improves  the 
traceability  of  the  model.  Traceability  of  the  model  is  critical  in  supporting  validation. 
Face  validation  techniques  are  normally  applied  when  validating  a  NOS,  as  actual  data 
may  not  exist  to  apply  mathematical  or  simulation  solutions.  ICoMM  demonstrated  that 
the  operational  validation  of  models  of  a  NOS  could  be  improved  with  greater 
involvement  of  stakeholders  by  soliciting  their  values.  Ultimately,  the  stakeholders 
validate  the  models  of  systems.  The  DOD  defines  validation  as  the  following: 

The  process  of  determining  the  degree  to  which  a  model,  simulation,  or 
federation  of  models  and  simulations,  and  their  associated  data  are 
accurate  representations  of  the  real  world  from  the  perspective  of  the 
intended  use(s).  (Department  of  Defense  2009,  9) 

Scenarios  of  potential  future  conflicts  had  to  be  created  to  gain  an  understanding 
of  the  unknown  environment.  This  research  chose  to  continue  to  model  the  HA/DR 
scenario  of  EW10  previously  studied  by  NPS  SE  students  and  Georgia  Tech  to  apply 
ICoMM  for  comparison.  The  scenario  demonstrated  that  the  non-observable  aspect  of  the 
system  was  the  interaction  with  the  external  system.  Specification  of  the  system  was  well 
known.  However,  the  effects  of  the  systems  functions  interacting  with  the  external  system 
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were  not  known  and  non-observable.  Thus,  operational  validation  of  the  system  was  not 
feasible  and  the  only  method  to  support  operational  validation  was  through  model 
exploration  of  the  CoM. 

B.  CONCLUSIONS 

This  research  clearly  demonstrated  the  utility  of  ICoMM  in  building  well- 
structured  CoMs  by  using  SE  and  SA  processes.  Face  and  traces  validation  methods  used 
for  conceptual  models  are  also  improved  using  the  SE  and  SA  processes  using  ICoMM. 
This  demonstration  can  be  applied  to  future  military  operational  assessments  process.  The 
methodology  supports  the  following  characteristics: 

•  Traceability — provides  the  stakeholders  the  ability  to  trace  from  MOPs 
and  measures  of  effectiveness  (MOEs)  to  fundamental  objectives. 

•  Validation — supports  face  validation  techniques  traditionally  used  models 
and  simulations  of  military  operation  by  involving  stakeholders  early  in 
the  architecting  process. 

•  Iterative — provides  a  method  that  can  be  repeated  for  different  operational 
situations. 

Figure  64  presents  an  overview  of  the  dissertation  of  applying  ICoMM  to  model 
development.  Starting  from  the  top-left  comer,  this  research  integrated  SE  and  SA 
processes  into  Sargent’s  (2001)  Evolved  MDP.  The  SE  and  SA  processes  decomposed 
the  system  to  begin  building  the  CoM  in  the  top-right  comer.  The  bottom-right  comer 
shows  a  refined  structure  of  the  CoM  that  identifies  the  measurements  and  the  supported 
objectives.  Finally,  the  bottom-left  comer  shows  the  table  of  functions  with  SME  inputs 
to  provide  quantifiable  measurements  to  the  NOS. 
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Figure  64.  Dissertation  Overview 


Several  things  were  revealed  as  a  result  of  this  research.  There  are  many  MDPs, 
but  this  research  has  not  found  one  that  demonstrates  clearly  how  to  transfer  the  systems 
definition  to  the  development  of  the  CoM.  Many  mention  systems  definition  as  a  part  of  a 
MDP,  but  do  not  clearly  outline  the  methodology.  It  is  understood  that  most  models  built 
are  of  systems.  Therefore,  an  understanding  of  SE  processes  if  vital  to  building  a  model 
that  represents  the  system. 

The  next  revelation  was  that  SMEs  must  be  actively  involved  in  building  the 
model.  The  SMEs  evaluate  the  model  for  correctness  in  representing  the  system  in  as  real 
world  environment  and  present  their  findings  to  DMs,  which  influences  their  decisions. 

C.  FUTURE  WORK 

This  research  was  a  continuation  of  a  recent  study  of  the  modeling  of  NOSs  for 
simulation.  There  remain  a  large  number  of  potential  extensions  of  this  work.  SE 
methodology  was  used  in  this  research  to  decompose  the  system  and  to  build  an 
architecture  that  would  improve  the  model  of  a  NOS  and  the  traceability  for  validation  of 
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the  model.  The  logical  following  step  would  be  to  find  a  simulation  model  that  would  use 
the  steps  outlined  in  this  research  to  model  the  system  and  allow  traceability  from  the 
measurements  to  the  fundamental  objectives.  There  has  been  research  in  conceptual 
models  for  discrete  event  simulations  (DES).  ICoMM  may  potentially  be  applied  to  build 
the  initial  state  of  the  system  for  DES. 

Another  extension  of  this  research  would  be  to  develop  a  system  of  systems 
(SOS).  This  research  considers  the  interaction  of  the  system  and  an  external  system  but 
not  the  subsystems.  SOS  has  five  characteristics:  operational  independence,  managerial 
independence,  geographically  distributed,  emergent  behavior,  and  evolutionary 
development  (Rainey  and  Tolk  2014).  These  characteristics  were  not  considered  in  this 
research.  There  would  definitely  be  new  challenges  to  trying  to  observe  different  systems 
performing  with  the  five  characteristics.  The  appearance  of  emergent  behavior  within  the 
SOS  and  accounting  for  the  unobservable  behavior  with  the  interaction  of  the  external 
system  would  be  very  difficult. 

Finally,  applying  this  method  in  a  real  world  environment  would  be  the  most 
desirable.  This  research  was  conducted  with  the  military  planners  and  assessment  officers 
in  mind.  Any  application  that  has  the  potential  to  assist  these  staff  officers  in  conducting 
their  daily  business  would  be  greatly  beneficial  to  the  U.S.  military. 
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APPENDIX  A.  VITECH  CORE  OUTPUTS 


OUTPUT  PART  1  -  Functions  List 

EXF.O  Perform  Country  of  Orange  Functions 
EXF.l  Provides  Internal  Security  (GOO) 

EXF.2  Receive  Aid 

EXF.3  Perform  Hostile  Group  Functions 
FUN.O  Provide  Regional  Stability 
FUN.l  Provide  Security 

FUN.  1.1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN.2  Provide  HA/DR 

FUN.2.1  Perform  Air  Connector 

FUN.2. 2  Perform  Surface  Connector 

FUN.2. 3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.1  Performs  Resupply  functions  (Sea  Base) 

FUN.3.2  Perform  Sea  Connector 
FUN.4  Provide  Infrastructure  Repair 

Part  II  -  Behavior  Model _ 

EXF.O  Perform  Country  of  Orange  Functions 

Allocated  To: 

EXS.l  Government  of  Orange 

Table  1  EXF.O  Perform  Country  of  Orange  Functions  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Disaster  Relief  Conducted 

Input  To: 

EXF.O  Perform  Country  of  Orange  Functions 

Output  From: 

FUN.2  Provide  HA/DR 

Secure  Area 

Input  To: 

EXF.O  Perform  Country  of  Orange  Functions 

Output  From: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

State  of  the  Country 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 
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Table  1  EXF.O  Perform  Country  of  Orange  Functions  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

FUN. 2  Provide  HA/DR 

FUN. 3  Provide  Command  and  Control 

Output  From: 

EXF.O  Perform  Country  of  Orange  Functions 

Table  1  EXF.O  Perform  Country  of  Orange  Functions  Interfacing  Items 


effbd  Perform  Country  of  Orange  Functions 


Univers'ty  Edition  -  For  Academic  Us  Only 

Date: 

August  5,  2015 

Figure  1  Perform  Country  of  Orange  Functions  (Enhanced  FFBD) 
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idefO  Perform  Country  of  Orange  Functions 


Attack  Convoy 


State  of  Security 
State  of  the  Country 


D  isaste  r  R  eli  ef  C  ond  ucted 
Secure  Area 


Secure  Area 


State  of  the  Country 


Government  of  Orange 


Hostile  Forces 


Date: 


University  Edition  -  For  Academic  Use  Only 


August  5,  2015 


Figure  2  Perform  Country  of  Orange  Functions  (IDEFO  Diagram) 


act  Perform  Country  of  Orange  Functions 
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Date: 

University  Edition  -  For  Academic  Use  Only 

August  5,  2015 

Figure  3  Perform  Country  of  Orange  Functions  (Activity  Diagram) 

EXF.l  Provides  Internal  Security  (GOO) 


Allocated  To: 

EXS.l  Government  of  Orange 
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Table  2  EXF.l  Provides  Internal  Security  (GOO)  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Secure  Area 

Input  To: 

EXF.O  Perform  Country  of  Orange  Functions 

Output  From: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

State  of  Security 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN. 3  Provide  Command  and  Control 

Output  From: 

FUN.  1  Provide  Security 

State  of  the  Country 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 

FUN. 2  Provide  HA/DR 

FUN. 3  Provide  Command  and  Control 

Output  From: 

EXF.O  Perform  Country  of  Orange  Functions 

Figure  4  Provides  Internal  Security  (GOO)  (Enhanced  FFBD) 
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Figure  5  Provides  Internal  Security  (GOO)  (IDEFO  Diagram) 


Figure  6  Provides  Internal  Security  (GOO)  (Activity  Diagram) 


EXF.2  Receive  Aid 

Allocated  To: 

EXS.1.2  People  Of  Orange 

EXF.3  Perform  Hostile  Group  Functions 

Allocated  To: 

EXS.2  Hostile  Forces 


Table  3  EXF.3  Perform  Hostile  Group  Functions  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Attack  Convoy 

Triggers  Function(s): 

EXF.3  Perform  Hostile  Group  Functions 
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FUN.O  Provide  Regional  Stability 

Allocated  To: 

0  HA/FA  Mission 


Figure  7  Provide  Regional  Stability  (Enhanced  FFBD) 
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idefO  Provide  Regional  Stability  ) 


Disaster  Relief  Opera  ling  Guide 


University  Edition  -  For  Academic  Use  Only 

Date: 

August  5,  2015 

Figure  8  Provide  Regional  Stability  (IDEFO  Diagram) 
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Figure  9  Provide  Regional  Stability  (Activity  Diagram) 


FUN.l  Provide  Security 

Allocated  To: 

0  HA/FA  Mission 

Specified  By  Requirements: 

REQ.2.1  Provide  Security  (Sea) 

REQ.3.1  Provide  Security  (Air) 

REQ.4.2  Provide  Security  (Surface) 
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Table  4  FUN.l  Provide  Security  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

Output  From: 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

FUN. 2. 3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Secure  Area 

Input  To: 

EXF.O  Perform  Country  of  Orange  Functions 

Output  From: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

State  of  Security 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN. 3  Provide  Command  and  Control 

Output  From: 

FUN.  1  Provide  Security 

State  of  the  Country 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 

FUN. 2  Provide  HA/DR 

FUN. 3  Provide  Command  and  Control 

Output  From: 

EXF.O  Perform  Country  of  Orange  Functions 

Unsecure  Area 

Input  To: 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 
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idefO  Provide  Security  J 


Unsecure  Area  ■ 


State  of  the  Country 


Command  and  cd^fe^ter  Relief  Operating  Guide 


FUN.  1.1 


Provide  Security 
for  distribution  of 
Aid 


-►  Secure  Area 

State  of  Security 


_ I _ t 

FUN.  1.2 


Provide  Internal 
Force  Protection 


FP  Maintained 


HA/FA  Mission 


University  Edition  -  For  Academic  Use  Only 


Date: 


August  5,  2015 


Figure  11  Provide  Security  (IDEFO  Diagram) 
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Figure  12  Provide  Security  (Activity  Diagram) 


FUN.  1.1  Provide  Security  for  distribution  of  Aid 

Allocated  To: 

0  HA/FA  Mission 

Table  5  FUN.1.1  Provide  Security  for  distribution  of  Aid  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

Output  From: 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

FUN. 2. 3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 
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Table  5  FUN.1.1  Provide  Security  for  distribution  of  Aid  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

FP  Maintained 

Input  To: 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

Output  From: 

FUN.1.2  Provide  Internal  Force  Protection 

Secure  Area 

Input  To: 

EXF.O  Perform  Country  of  Orange  Functions 

Output  From: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

Unsecure  Area 

Input  To: 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 
FUN.1.2  Provide  Internal  Force  Protection 

Table  6  FUN.1.2  Provide  Internal  Force  Protection  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 
FUN.1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

Output  From: 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 
FUN.1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

FUN. 2. 3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

FP  Maintained 

Input  To: 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

Output  From: 

FUN.1.2  Provide  Internal  Force  Protection 

Unsecure  Area 

Input  To: 
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Table  6  FUN.1.2  Provide  Internal  Force  Protection  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 
FUN.1.2  Provide  Internal  Force  Protection 

FUN.2  Provide  HA/DR 

Allocated  To: 

0  HA/FA  Mission 

Table  7  FUN.2  Provide  HA/DR  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 
FUN.1.2  Provide  Internal  Force  Protection 

FUN.2  Provide  HA/DR 

FUN.2. 1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

Output  From: 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Disaster  Area 

Input  To: 

FUN.2  Provide  HA/DR 

Disaster  Relief  Conducted 

Input  To: 

EXF.O  Perform  Country  of  Orange  Functions 

Output  From: 

FUN.2  Provide  HA/DR 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 
FUN.1.2  Provide  Internal  Force  Protection 

FUN.2  Provide  HA/DR 

FUN.2. 1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

FUN. 2. 3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

State  of  HA/DR 

Input  To: 

FUN. 3  Provide  Command  and  Control 

Output  From: 

FUN.2  Provide  HA/DR 

State  of  the  Country 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

125 


Table  7  FUN.2  Provide  HA/DR  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

FUN.  1  Provide  Security 

FUN.2  Provide  HA/DR 

FUN. 3  Provide  Command  and  Control 

Output  From: 

EXF.O  Perform  Country  of  Orange  Functions 

Figure  13  Provide  HA/DR  (Enhanced  FFBD) 
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idefO  Provide  HA/DR  ) 


Command  and  Control  Disaster  Relief  Operating  Glide 


Aid/Supplies 


Disaster  A  tea 
State  of  the  Country 


SH60 


LCU 


FLSS 


D  isaste  r  R  eli  ef  C  ond  ucted 
State  of  HA/DR 


Distribution  of  Aid/Supplies 


HA/FA  Mission 


Date: 


University  Edition  -  For  Academic  Use  Only 


August  5,  2015 


Figure  14  Provide  HA/DR  (IDEFO  Diagram) 
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FUN.2.1  Perform  Air  Connector 


Allocated  To: 

COMP. 2.2  SH60 
COMP. 2. 3  OV22 


Table  8  FUN.2.1  Perform  Air  Connector  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Aid/Supplies 

Input  To: 

FUN.2.1  Perform  Air  Connector 

FUN.2.2  Perform  Surface  Connector 

Output  From: 

FUN. 3.1  Performs  Resupply  functions  (Sea  Base) 
FUN.3.2  Perform  Sea  Connector 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN.2.1  Perform  Air  Connector 

FUN.2.2  Perform  Surface  Connector 

Output  From: 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Delivery  by  Air 

Input  To: 

FUN. 2. 3  Perform  Forward  Logistics 

Output  From: 

FUN.2.1  Perform  Air  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN.2.1  Perform  Air  Connector 

FUN.2.2  Perform  Surface  Connector 

FUN. 2. 3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

FUN.2.2  Perform  Surface  Connector 

Allocated  To: 
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COMP. 3.1  LCAC 
COMP. 3.2  LCU 


Table  9  FUN.2.2  Perform  Surface  Connector  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Aid/Supplies 

Input  To: 

FUN. 2.1  Perform  Air  Connector 

FUN.2.2  Perform  Surface  Connector 

Output  From: 

FUN. 3.1  Performs  Resupply  functions  (Sea  Base) 
FUN.3.2  Perform  Sea  Connector 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN.2.2  Perform  Surface  Connector 

Output  From: 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Delivery  by  Surface 

Input  To: 

FUN.2.3  Perform  Forward  Logistics 

Output  From: 

FUN.2.2  Perform  Surface  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN.2.2  Perform  Surface  Connector 

FUN.2.3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

FUN.2.3  Perform  Forward  Logistics 

Allocated  To: 

COMP.4.1  FLS 
COMP.4.2  FLSS 
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Table  10  FUN.2.3  Perform  Forward  Logistics  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Delivery  by  Air 

Input  To: 

FUN.2.3  Perform  Forward  Logistics 

Output  From: 

FUN. 2.1  Perform  Air  Connector 

Delivery  by  Surface 

Input  To: 

FUN.2.3  Perform  Forward  Logistics 

Output  From: 

FUN. 2. 2  Perform  Surface  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

FUN.2.3  Perform  Forward  Logistics 

FUN.3  Provide  Command  and  Control 

FUN.3. 2  Perform  Sea  Connector 

Distribution  of  Aid/Supplies 

Output  From: 

FUN.2.3  Perform  Forward  Logistics 

FUN.3  Provide  Command  and  Control 

Allocated  To: 

0  HA/FA  Mission 


Table  11  FUN.3  Provide  Command  and  Control  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

Output  From: 

FUN.3  Provide  Command  and  Control 

FUN.3. 2  Perform  Sea  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 
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Table  11  FUN.3  Provide  Command  and  Control  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

FUN. 2. 3  Perform  Forward  Logistics 

FUN.3  Provide  Command  and  Control 

FUN.3. 2  Perform  Sea  Connector 

State  of  HA/DR 

Input  To: 

FUN.3  Provide  Command  and  Control 

Output  From: 

FUN. 2  Provide  HA/DR 

State  of  Security 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.3  Provide  Command  and  Control 

Output  From: 

FUN.  1  Provide  Security 

State  of  the  Country 

Input  To: 

EXF.l  Provides  Internal  Security  (GOO) 

FUN.  1  Provide  Security 

FUN. 2  Provide  HA/DR 

FUN.3  Provide  Command  and  Control 

Output  From: 

EXF.O  Perform  Country  of  Orange  Functions 

Figure  16  Provide  Command  and  Control  (Enhanced  FFBD) 
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Figure  17  Provide  Command  and  Control  (IDEFO  Diagram) 


Figure  18  Provide  Command  and  Control  (Activity  Diagram) 
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FUN.3.1  Performs  Resupply  functions  (Sea  Base) 

Allocated  To: 

0  HA/FA  Mission 


Table  12  FUN.3.1  Performs  Resupply  functions  (Sea  Base)  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Aid  from  Resupply  Ship 

Input  To: 

FUN.3.1  Performs  Resupply  functions  (Sea  Base) 
FUN.3.2  Perform  Sea  Connector 

Aid/Supplies 

Input  To: 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

Output  From: 

FUN.3.1  Performs  Resupply  functions  (Sea  Base) 
FUN.3.2  Perform  Sea  Connector 

FUN.3.2  Perform  Sea  Connector 

Allocated  To: 

COMP.  1.2  LHD 
COMP.  1.3  LPD 
COMP.  1.4  LSD 


Table  13  FUN.3.2  Perform  Sea  Connector  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Aid  from  Resupply  Ship 

Input  To: 

FUN.3.1  Performs  Resupply  functions  (Sea  Base) 
FUN.3.2  Perform  Sea  Connector 

Aid/Supplies 

Input  To: 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

Output  From: 

FUN.3.1  Performs  Resupply  functions  (Sea  Base) 
FUN.3.2  Perform  Sea  Connector 

Command  and  Control 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 
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Table  13  FUN.3.2  Perform  Sea  Connector  Interfacing  Items 


Interfacing  Items 

Source  /  Destination 

Output  From: 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

Disaster  Relief  Operating  Guide 

Triggers  Function(s): 

FUN.  1  Provide  Security 

FUN.  1 . 1  Provide  Security  for  distribution  of  Aid 

FUN.  1.2  Provide  Internal  Force  Protection 

FUN. 2  Provide  HA/DR 

FUN. 2.1  Perform  Air  Connector 

FUN. 2. 2  Perform  Surface  Connector 

FUN. 2. 3  Perform  Forward  Logistics 

FUN. 3  Provide  Command  and  Control 

FUN.3.2  Perform  Sea  Connector 

{tc  “6  Components  Part  I  -  Components  List 


0  HA/FA  Mission 

COMP.l  Sea  Base  Connector 

COMP.  1.2  LHD 

COMP.  1.3  LPD 

COMP.  1.4  LSD 

COMP. 2  Air  Connector 

COMP. 2.1  MH53 

COMP. 2.2  SH60 

COMP. 2. 3  OV22 

COMP. 3  Surface  Connector 

COMP. 3.1  LCAC 

COMP. 3.2  LCU 

COMP.4  Logistcal  Sites 

COMP.4.1  FLS 

COMP.4.2  FLSS 

EXS.l  Government  of  Orange 

EXS.1.2  People  Of  Orange 

EXS.2  Hostile  Forces 


Part  II  -  Component  Definitions 
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0  HA/FA  Mission 


Type:  System  of  Systems 

Built  From  Lower-Level  Component(s): 
COMP.l  Sea  Base  Connector 
COMP.4  Logistcal  Sites 
EXS.l  Government  of  Orange 
EXS.2  Hostile  Forces 


Figure  19  HA/FA  Mission  (Physical  Block  Diagram) 

Performs  Function(s): 

FUN.O  Provide  Regional  Stability 
FUN.l  Provide  Security 

FUN.  1.1  Provide  Security  for  distribution  of  Aid 
FUN.  1.2  Provide  Internal  Force  Protection 
FUN.2  Provide  HA/DR 
FUN. 3  Provide  Command  and  Control 
FUN.3.1  Performs  Resupply  functions  (Sea  Base) 


COMP.l  Sea  Base  Connector 

Description: 

The  system  context  identifies  the  physical  context  (the  environment  and  external  systems 
your  system  interacts  with)  enabling  you  to  specify  the  system  boundary. 

Type:  System  of  Systems 

Built  In  Higher-Level  Component(s): 

0  HA/FA  Mission 

Built  From  Lower-Level  Component(s): 

COMP. 2  Air  Connector 
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COMP. 3  Surface  Connector 


pbd  Sea  Base  Connector  ~f 


University  Edition  -  For  Academic  Use  Only 

Date: 

August  5,2015 

Figure  20  Sea  Base  Connector  (Physical  Block  Diagram) 


Connected  to  Physical  Link(s): 

Sea  to  Air 
Surface  Connector 

COMP.1.2  LHD 

Type:  System 

Performs  Function(s): 

FUN.3.2  Perform  Sea  Connector 
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COMP.1.3  LPD 

Performs  Function(s): 

FUN.3.2  Perform  Sea  Connector 

COMP.1.4  LSD 

Performs  Function(s): 

FUN.3.2  Perform  Sea  Connector 

COMP.2  Air  Connector 

Type:  Subsystem 

Built  In  Higher-Level  Component(s): 
COMP.l  Sea  Base  Connector 

Connected  to  Physical  Link(s): 

Air  to  FLS 
Air  to  FLSS 
Air  to  Log 
Sea  to  Air 

COMP.2. 1  MH53 
COMP.2.2  SH60 

Performs  Function(s): 

FUN.2.1  Perform  Air  Connector 

COMP.2.3  OV22 

Performs  Function(s): 

FUN.2.1  Perform  Air  Connector 

COMP.3  Surface  Connector 

Type:  Subsystem 

Built  In  Higher-Level  Component(s): 
COMP.l  Sea  Base  Connector 

Connected  to  Physical  Link(s): 

Surface  Connector 
Surface  to  FLS 
Surface  to  FLSS 
Surface  to  Log 

COMP.3. 1  LCAC 

Performs  Function(s): 

FUN.2.2  Perform  Surface  Connector 
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COMP.3.2  LCU 

Performs  Function(s): 

FUN.2.2  Perform  Surface  Connector 

COMP.4  Logistcal  Sites 

Built  In  Higher-Level  Component(s): 

0  HA/FA  Mission 

Connected  to  Physical  Link(s): 

Air  to  Log 
Log  to  People 
Surface  to  Log 

COMP.4. 1  FLS 

Performs  Function(s): 

FUN.2.3  Perform  Forward  Logistics 

COMP.4.2  FLSS 

Performs  Function(s): 

FUN.2.3  Perform  Forward  Logistics 

EXS.l  Government  of  Orange 

Type:  External  System 

Built  In  Higher-Level  Component(s): 

0  HA/FA  Mission 

Built  From  Lower-Level  Component(s): 
EXS.l. 2  People  Of  Orange 
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Figure  21  Government  of  Orange  (Physical  Block  Diagram) 


Connected  to  Physical  Link(s): 

Provide  Internal  Security 

Performs  Function(s): 

EXF.O  Perform  Country  of  Orange  Functions 
EXF.l  Provides  Internal  Security  (GOO) 


EXS.1.2  People  Of  Orange 

Type:  Context 

Built  In  Higher-Level  Component(s): 
EXS.l  Government  of  Orange 

Connected  to  Physical  Link(s): 
FLC-POO 
FLSS-POO 
Hostile  Intent 
Influence  People 
Influence  People  of  Orange 
Internal  Security 
Log  to  People 
Provide  Internal  Security 

Performs  Function(s): 

EXF.2  Receive  Aid 

EXS.2  Hostile  Forces 


Type:  Context 
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Built  In  Higher-Level  Component(s): 

0  HA/FA  Mission 

Connected  to  Physical  Link(s): 

Influence  People  of  Orange 

Performs  Function(s): 

EXF.3  Perform  Hostile  Group  Functions 
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APPENDIX  B.  VEHICLE  PLATFORM  SPECIFICATIONS 


The  following  table  is  the  list  of  capabilities  for  each  of  the  platforms  used  in  the 
HA/DR  mission. 


Sea  Base 


LHD 


LPD 


LSD 


Sea  Connectors 


LCAC 


LCU 


Air  Connectors 


MH-53 


SH-60 


Velocity  (kts)  -  SeabaseOps 


40 


150 


215 


160 


Payload  (U.S.  tons) 


2711.69 


2535,32 


1234,59 


75 


170 


18 


17,5 


Fuel  Capacity 


314160 


5000 


2277 


590 


Refuel  Initiation  Threshold  {%) 


30 


30 


30 


30 


30 


30 


Refuel  Completion  Threshold  (%) 


95 


95 


95 


100 


100 


100 


100 


100 


Refuel  Rate  (at  sea  -  Gal/hr) 


252000 


252000 


252000 


60000 


Replenishment  Initiation  Threshold  (%) 


Replenishment  Completion  Threshold  (%} 
Replenishment  Rate  (at  sea  •  U.S.  Tons/hr) 
Load  lime  (Hr) 

Unload  Time  (Hr) 

Range  before  Refuel  (Nmi) 

Fuel  Consumption  time  (Hr) 

Operating  Time  Limit  (Hr/Day) 


2 

4,5 

0,01666667 

r0, 03333333 

0,01666667 

2 

4,5 

0*6666] 

'0.03333333 

0,01666667 

200 

1200 

700 

950 

450 

5 

150 

4,67 

4,4 

2.8 

1  16 

16 

8 

8 

8 
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